Support » Plugin: AMP » Sudden fall in lighthouse speed when redirecting mobile users to AMP

  • Resolved Bestwattage Dev

    (@bestwattageteam)


    I am using Google’s AMP plugin to enable AMP. Everything seems to be working fine until I enable the option to Redirect mobile users to AMP. Once enabled, the Lighthouse score for the Mobile got reduced drastically from 95+ to 65+. The same happens when I test for AMP URL (?amp).

    As per Thread I created a custom plugin to render AMP at server side, nothing worked out.

    I specifically noticed ‘Reduce initial Server response time’ at the lighthouse only for AMP URLs. Are there any settings or changes I need to make to fix this?

    I used, WP-Rocket for caching and GeneratePress as a theme. please do suggest if there is a way to overcome the issue.

    Screenshots:
    Mobile (Actual issue): https://pasteboard.co/K5cBHtT.png
    Desktop (Expected and working): https://pasteboard.co/K5cCrNF.png

    The page I need help with: [log in to see the link]

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author Weston Ruter

    (@westonruter)

    Are you sure you have page caching enabled? I’m seeing 2.24 seconds for the server to respond to a request for the AMP page.

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    Yeah, enabled by using WP-Rocket(https://pasteboard.co/K5dS7OI.png). Server response time issue happening only for AMP pages, not for non-amp pages. I believe wp rocket won’t restrict caching of amp pages. Struggling for the past 3 weeks and not able to find the proper solution as such. please do let me know if I am missing anything.

    Plugin Author Weston Ruter

    (@westonruter)

    Maybe you have caching disabled when query parameters are present? See https://docs.wp-rocket.me/article/971-caching-query-strings

    I think you may just need to add “amp” to the list of “Cache Query String(s)”

    Plugin Author Weston Ruter

    (@westonruter)

    I would also suggest you submit a support topic to WP Rocket to ask them to add amp by default as one of the query parameters that gets cached.

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    Thanks, @westonruter really helpful.

    One more thing I noticed is though ‘Redirect mobile visitors to AMP’ is turned ON. when I entered the non-AMP URL at Page insights, As mentioned in screenshots, it’s expected to load AMP URL(?amp) at the mobile and non-amp URL at the desktop(as shown in my initial thread Screenshots). But, it’s showing a non-amp URL for both mobile and desktop. Did anything changed at page insights in this short span or am I missing anything?

    Also, I will post the same at WProcket support of asking them to add amp value as default.

    Plugin Author Weston Ruter

    (@westonruter)

    One more thing I noticed is though ‘Redirect mobile visitors to AMP’ is turned ON. when I entered the non-AMP URL at Page insights, As mentioned in screenshots, it’s expected to load AMP URL(?amp) at the mobile and non-amp URL at the desktop(as shown in my initial thread Screenshots). But, it’s showing a non-amp URL for both mobile and desktop. Did anything changed at page insights in this short span or am I missing anything?

    I see it is loading the ?amp URL. The screenshot for mobile shows “Requested URL redirected to: …?amp”.

    Note that by default mobile redirection is done client-side with JavaScript. This is because it is found to be more compatible with various caching plugins. You may want to consider trying server-side redirection instead, as that will speed up the mobile redirection quite a bit. See this plugin to enable that: https://gist.github.com/westonruter/e5032d805625f0f743237708c43d3783

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    Thanks, @westonruter, installed the custom plugin from your repo.

    Also, the reason why I am not seeing the AMP URL at the lighthouse is an option at wp rocket (tested regression as well). Option under cache https://pasteboard.co/K5f2bqJ.png ‘Separate cache files for mobile devices playing a part here. When unchecked, URL is not redirecting to AMP. when checked, it’s redirecting to the Amp page (?amp).

    Also, the Speed for the AMP page is still not satisfying. One article WProcket AMP document indicates, it will just cache it will not minify or preload or do any other optimization stuff. That might be the reason for the slowness. but, nothing sure on the issue right now.

    Plugin Author Weston Ruter

    (@westonruter)

    Also, the Speed for the AMP page is still not satisfying. One article WProcket AMP document indicates, it will just cache it will not minify or preload or do any other optimization stuff. That might be the reason for the slowness. but, nothing sure on the issue right now.

    I believe WPRocket disables its additional optimizations on AMP pages because the AMP plugin does them itself.

    Something else to factor in is the speed of your AMP pages as served by the AMP Cache. Try pasting in the URL to an AMP page into the field shown at https://amp.dev/documentation/guides-and-tutorials/learn/amp-caches-and-cors/amp-cache-urls/?format=websites

    That will give you the URL to the page on the AMP Cache. You can then try running that through PageSpeed Insights as well to see how it behaves. The page on the AMP Cache is what mobile visitors would see when they find your content via Google Search.

    Nevertheless, the performance of AMP pages on origin should be further improved.

    I’m noticing that your logo is getting correctly identified as a hero (getting the data-hero attribute) so it will get prerendered, but I’m not seeing the same for the first image in the content (even though it has data-hero-candidate). It appears this is because you have two logos, one for desktop and one for mobile, and both of them are getting identified as a hero candidates and we currently only prerender the first two. And this is a source of delay for LCP.

    We are going to be lifting the restriction of 2 for prerendered hero images as mentioned here: https://github.com/ampproject/amp-toolbox-php/issues/55#issuecomment-825913927

    In the meantime, if you’re comfortable editing a file in the plugin, you could try editing vendor/ampproject/amp-toolbox/src/Optimizer/Transformer/PreloadHeroImage.php to change DATA_HERO_MAX from 2 to 3. See: https://github.com/ampproject/amp-wp/blob/2.1.2-built/vendor/ampproject/amp-toolbox/src/Optimizer/Transformer/PreloadHeroImage.php#L85

    This will improve your LCP.

    Two additional things that you could try is to preload those hero images. I put together a mini plugin to prototype that functionality: https://gist.github.com/westonruter/50abd71d9becb5a34f01136052effef5

    Additionally, you may want to consider elevating the link tags to be Link response headers which you can try with this plugin: https://gist.github.com/westonruter/8a171f6c561fd69ac33a032983dafaf3

    Something else I’m seeing, regardless of AMP, is that you are enqueueing the Open Sans font in a suboptimial way. You’re loading the stylesheet https://fonts.googleapis.com/css?family=Open+Sans%3A400%2C300%2C700&ver=5.7.2 which has two problems: it has a ver parameter and it is lacking display=optional. Read more about font-display:optional. This is the wp_enqueue_style() code you should use:

    wp_enqueue_style( 'google-font-open-sans', 'https://fonts.googleapis.com/css?family=Open+Sans%3A400%2C300%2C700&display=optional', [], null );

    I also see you’re enqueueing FontAwesome stylesheet but there is no text on the page that appears to be using the font. In general, icon fonts are bad for performance.

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    Got to know most of them are facing a similar kind of issue from https://github.com/GoogleChrome/lighthouse/issues/8932 Not sure about the solution. Just checked a couple of top websites with AMP feature in the country, even issue exists for them. AS mentioned at Git, looks like it’s majorly because of the Lighthouse compatibility for rendering the amp. I will wait if any genius has overcome the issue.

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    That is an awesome explanation @westonruter. That really makes sense to test the AMP domain( www-XXX-com.cdn.ampproject.org) page than trying amphtml page from my domain to lighthouse.

    I will try with all mentioned changes and update the same. Thanks for the extreme help.

    Thread Starter Bestwattage Dev

    (@bestwattageteam)

    Thank you @westonruter Speed improved a lot. Also replaced font-awesome with some CSS. your suggestions made a huge difference.

    Plugin Support Bethany Chobanian Lang

    (@shetheliving)

    Fantastic, glad that we were able to help! Please do feel free to leave a review – we’d love to hear your feedback on the plugin.

Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.