Pixi: Poor page experience (Slow LCP)

[CraigBusfield]

URL

https://www.gaborshoes.co.uk/homepage-ssr-runtime.html

Details

Metric	Field data	Lab data
LCP	n/a	3.6 s
FID	n/a	156 ms
CLS	n/a	0.00
HTTPS	pass	---
Safe browsing	pass	---
Mobile-friendliness	pass	---
Intrusive Interstitials	<pass/fail>	---

Notes

Components in use: amp-access, amp-animation, amp-bind, amp-consent, amp-form, amp-geo, amp-iframe, amp-install-serviceworker, amp-lightbox, amp-list, amp-mustache, amp-position-observer, amp-sidebar

We're testing out the use of the PHP AMP Optimizer, so this is just a static test page - we haven't applied the Optimizer to any of the actual 'live' pages on the site just yet, but it would be interesting to know if there's anything further we can do to improve our page experience and therefore Lighthouse score

/cc @ampproject/wg-performance

[kristoferbaxter]

Leaving comments as I take a look:

Image compression/selection can be improved

https://www.gaborshoes.co.uk/images/modules/promo_units/xsmall/1605280620-22344600.jpg
Original (delivered as WebP): 27.1kB
MozJPG: 20kB (26% smaller)
WebP: 14.6kB (46% smaller)
AVIF: 12.6kB (53% smaller)

Additional Hero Image candidates

Hero Images can be denoted with data-hero and do not require the JavaScript payload to download before requesting the contents of the image (they are done by the prescanner as the document is being parsed).

[kristoferbaxter]

Usage of many <amp-img> instead of srcset.

This element appears to occupy the same place in all of the design variants at different breakpoints, but is represented in the DOM as several different <amp-img> elements and uses CSS for mutual exclusion of content.

Each AMP component has a cost, and reducing this to a single <amp-img> (and in the future an <img> once support lands) will reduce the amount of JS work needed on the page. This pattern appears quite common in the markup.

[CraigBusfield]

Thanks @kristoferbaxter, that's great (and very speedy!) feedback, we'll get to work on the data-hero and the WebP optimisation points.

I would just like to query the last point you made as I might not be understanding you correctly but I'm not sure serving just one amp-img tag will work for us here. The reason being is that we allow our clients to change the art direction of these images on this page based on the screen width, and so the images have different dimension ratios at, for example, mobile and desktop screen widths. In non-AMP situations we'd leverage the picture element here, but I don't believe that is supported in AMP - is there any other alternative that we could use that would be more performant than what we currently have? I guess that the changes to deprecate amp-img may eventually open the door for picture to be made available?

Certainly in this instance we could combine some of the amp-img tags as they have the same dimension ratios but that isn't always going to be the case for all of our clients. The other thing is if we use srcset we've found that that won't allow the image be preloaded via the Optimizer so we would lose this benefit altogether anyway (it spits out the following message when we try "Not preloading the hero image because of the presence of a 'srcset' attribute")

[CraigBusfield]

@kristoferbaxter Just to let you know, we've created an updated version of that page at https://www.gaborshoes.co.uk/homepage-ssr-runtime-updated.html (this one has a new main image due to changes client has made on the live site) with the following improvements:

• More optimised images (main hero image is now 15.7kB, down from 27.1kB)
• Added data-hero attribute to the largest image on the page

However, we're not seeing any improvement in the Page Experience times (LCP is still 3.6s) and we feel like we've negatively impacted the page load on desktop devices because we can no longer preload images based on media queries as we were doing previously. I suppose this relates to the srcset issue discussed in previous comments, so I'll await your opinion on that one.

Thanks again for looking at this!

[kristoferbaxter]

I would just like to query the last point you made as I might not be understanding you correctly but I'm not sure serving just one amp-img tag will work for us here. The reason being is that we allow our clients to change the art direction of these images on this page based on the screen width, and so the images have different dimension ratios at, for example, mobile and desktop screen widths. In non-AMP situations we'd leverage the picture element here, but I don't believe that is supported in AMP - is there any other alternative that we could use that would be more performant than what we currently have? I guess that the changes to deprecate amp-img may eventually open the door for picture to be made available?

If there is the intention of using different images for the sake of art direction, then the usage of several <amp-img> components makes sense today. See: https://amp.dev/documentation/guides-and-tutorials/develop/style_and_layout/responsive_design/#changing-the-art-direction-of-an-image

However, it could be an option to ensure the different formats at each resolution are actually different output to avoid creating extra elements needlessly.

You're also right on that once HTMLImageElement is supported natively the HTMLPictureElement would be a great replacement. This is one of the reasons we are pushing for allowing HTMLImageElements in the DOM tree.

[kristoferbaxter]

The other thing is if we use srcset we've found that that won't allow the image be preloaded via the Optimizer so we would lose this benefit altogether anyway (it spits out the following message when we try "Not preloading the hero image because of the presence of a 'srcset' attribute")

This makes sense, but is a sad limitation from the Web Platform (across all supported user-agents). We've been exploring the usage of Client Hints and other proposals to see if we can come up with a viable alternative.

However, the benefit of preload for image resources should be quite small since the Preload Scanner should see the output of the HTMLImageElement inline inside an <amp-img> in a valid AMP Optimizer output. (lots of should's there)

The only exception I've seen would be if the document was a streaming response, where the preload header or meta element would be available before the next chunk of the document response. The benefit here should be small though for an individual document/domain.

[CraigBusfield]

Thanks again @kristoferbaxter, that explanation has really helped us to understand the AMP Optimizer a bit better, so we'll test a few other things and see how we get on, and we'll definitely see if we can find a nice way to consolidate those amp-img tags where possible without compromising display options for our clients. Great news about HTMLPictureElement (and HTMLImageElement), that'll be a fantastic addition to the AMP platform!

One last question fo you at the minute, do you have details of the rough location of the AMP Page Experience Guide test servers? Couldn't see any docs about it so we were just wondering if it was North America-based, or if there are more local locations globally.

We're UK-based and the site doesn't leverage a CDN currently so we're just wondering if location is a big factor here too. Testing via WebPageTest on a UK-based server we see an LCP of 2.9s which is a lot closer to meeting the Core Web Vitals threshold: https://www.webpagetest.org/lighthouse.php?test=201116_DiB1_131a036c50f0e1068ea132a81c4943ec&run=1

[kevinkimball]

@CraigBusfield the lab data is collected via PageSpeed Insights tool - it is the same lab data you would see there. Based on some of the previous pages we've tested I do believe the servers are NA based and that could be a factor in your scoring. That being said, using a CDN is a great way to speed up your site :)

[CraigBusfield]

Thanks for the info @kevinkimball, that's really helpful! I'll close this issue for now but you're not getting rid of me so easy - I've added another issue for the listings page of the site at #62

I'm so sorry! 😢 But also really grateful for yours and @kristoferbaxter help on these points!

[CraigBusfield]

Hi @kristoferbaxter and @kevinkimball - sorry for re-opening this issue, but spotted something related to this that I'd like your opinions on please.

I ran this Lighthouse test, where LCP is coming back as 3.2s, so I decided to have a look at the Performance timeline to get a better idea of what was going on and I noticed that the main "20% Off" image (which is highlighted in the LH test as the LCP element) actually gets loaded in and is fully visible on screen at around 1.3s:

Just wondering if you guys have any idea why LCP isn't credited until 3.2s? It seems to me as though that content is loaded and fully available to the user much before that time.

Or would this be more of a question for the Lighthouse team?

[kristoferbaxter]

Taking another look, here are some layout shift improvement opportunities.

Before	After

These are trackable from devtools.

[CraigBusfield]

Hi @kristoferbaxter, just picking back up on this.

Thanks for the advice on the CLS issue, turned out it was a bug that we'd introduced when using the AMP Toolbox. I've fixed that now and we've actually applied SSR to the live homepage of the site: https://www.gaborshoes.co.uk/

It seems to have given us a performance boost in some stats but when testing https://www.gaborshoes.co.uk/ the AMP Page Experience Guide is still telling us that we have slow LCP (4.0s) and TBT (317ms). Do you have any advice on anything we could do to resolve this please?

There is a recommendation to "Ensure initial Server-response time for the page is short" but that's being measured at 178.07ms which seems pretty good to me (I believe Page Speed Insights only fails the audit on anything above 600ms).

Thanks,
Craig

[CraigBusfield]

Actually, ignore the LCP issue - just realised that'll be related to GoogleChrome/lighthouse#11706, assuming Page Speed Insights/AMP Page Experience Guide is still testing on an older version of Chrome, so that should resolve itself eventually.

So it's just the TBT metric that we could do with some help on if you have any advice please 😄

[kristoferbaxter]

Some clarity: for 2020 Core Web Vitals will not use TBT as a metric, only FID.

However, TBT is still important to keep low for user-experience... so I took a look. Here are some incomplete findings as I examine:

Analytics is doing a lot of work here. This is a common slice of work in a long task.

Are there a lot of analytics vendors or information being collected?

[CraigBusfield]

Hi @kristoferbaxter,

Thanks for taking a look!

On that page there are 3 analytics vendors being used, with 4 initial analytics hits on page load:

• Google Analytics (1 analytics hit to register page view and promo impressions and 1 analytics hit to record page timing info)
• Facebook Pixel (1 analytics hit to record pageview)
• Snowplow v2 (1 analytics hit to record pageview and page timing info, plus subsequent "ping" events at 30 second intervals)

Would this be considered excessive analytics usage for an AMP page? Or is it maybe an issue with how we have set these amp-analytics tags up?

Thanks,
Craig