LCP with <picture> element

327 views
Skip to first unread message

Jordan Barber

unread,
Feb 3, 2021, 4:29:40 PM2/3/21
to Chrome UX Report (Discussions)
My team is working diligently on our Largest Contentful Paint across our web application. I have a question (which I cannot find much info on) around LCP and <picture> elements with multiple sources.

We have a specific part of our web app where a large gallery image accounts for LCP. We have been trying to get this element in the green (< 2.5s ). We have taken quite a few approaches and have been able to get that LCP element down from 14 to 4. The last step (or at least I was hoping) was to render webp's inside the picture tag to get that LCP element to load quicker via a smaller image byte size. I thought this would give big gains, but in fact it turns out that we didn't see a change. The only thing that I can infer from this is that reports are looking at the fallback image (which was not changed to webp as it's for non-webp browsers).

Does anyone have any insight into this?

Gilberto Cocchi

unread,
Feb 3, 2021, 6:44:04 PM2/3/21
to Jordan Barber, Chrome UX Report (Discussions)
Hi Jordan, nice to e-meet you.

Are you comfortable with sharing some more info on they way you were testing this LCP improvement?

When you mention 14 to 4s, do you mean Lab LCP improvement or Field LCP? Because it's possible that they might differ depending on your site browser screen size population and connectivity.

Also do you mind telling me if we are talking about Mobile or all devices LCP?

What I would usually suggest to check if images are larger the necessary, also considering High Density screens there is a limit while going over it may reflect on wasting bandwidth without noticing any better looking images.

I've seen many sites being able to improve Field LCP by capping Images to 2x High Density multipliers achieving great results on LCP.
How big are images when delivered to mobile screens?

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/d18a3282-677c-4f6b-b460-837c3ef7ef48n%40chromium.org.


--

gTech Up

Gilberto Cocchi
Web Ecosystem Consultant
gilb...@google.com
+39 02 3661 8337

Google Italy | Via Federico Confalonieri 4 | Porta Nuova Isola | Building C | Milan 20124

Registered in Milan, Italy


This email may be confidential and privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

Jordan Barber

unread,
Feb 4, 2021, 11:35:38 AM2/4/21
to Chrome UX Report (Discussions), Gilberto Cocchi, Chrome UX Report (Discussions), Jordan Barber
Hi Gilberto,

Thanks for the in-depth response.

I am testing this in the field at a mobile size.

We've done a good bit of work to make sure we're delivering the right image sizes, but my question is just around using a dynamic <picture> element with many sources. Because I didn't see an improvement in LCP for the main image when I switched from png to webp (except for the fallback) image - this is leading me to believe that Google is looking at that fallback image to judge LCP, but I'm having a hard time proving this theory.

Take the following code:

<picture>
    <source media="(max-width: 767px)" type="image/webp" srcset="{{ mainImage.images.f ~ '&fmt=webp' }}">
    <source media="(max-width: 767px)" type="image/png" srcset="{{ mainImage.images.f }}">
    <source media="(max-width: 768px)" type="image/webp" srcset="{{ mainImage.images.f2x ~ '&fmt=webp' }}">
    <source media="(min-width: 768px)" type="image/png" srcset="{{ mainImage.images.f2x }}">
    <img class="gallery__main-image" src="{{ mainImage.images.t2x }}" width="1200" height="800">
</picture>

The webp's were recently added and I have checked in the network to make sure this technique works. Webps load at proper viewports for Chrome and pngs load for proper viewports on Safari. However switching to webp for Chrome (a 70% reduction in byte size) did not improve our LCP score. Which is what leads me to believe that Chrome is looking at the fallback <img> to score LCP. Perfectly fine if so, I just need to know if this is true so I take the next steps in getting our LCP sub 2.5 s.

Thanks again!

Jordan

Andrew Limn

unread,
Feb 4, 2021, 11:46:38 AM2/4/21
to Chrome UX Report (Discussions), jor...@creativemarket.com, Gilberto Cocchi, Chrome UX Report (Discussions)
  Hi Jordan,

When you say that LCP hasn't changed after adding WebP images, are you looking at the field data in page speed insights, as that's a rolling 30 day average, so you won't see the full impact of your fix on the real user metrics for 30 days. You would expect to see an immediate improvement in the lab data however.

I'm currently adding the same optimization to a client's site, so I'm very interested in your issue here.

Thanks,

Andy

Jordan Barber

unread,
Feb 4, 2021, 11:55:18 AM2/4/21
to Andrew Limn, Chrome UX Report (Discussions), Gilberto Cocchi
Hey Andy,

Cool - I'll definitely keep you posted.

Where I would expect to see immediate results (viewing the LCP element in the Performance recording), I am not seeing any gains - sorry I guess that's Lab data.

Thanks,

Jordan


This email and any attachments contains privileged and confidential information intended only for the use of the addressee(s). If you are not an intended recipient of this email, you are hereby notified that any dissemination, copying or use of information is strictly prohibited. If you received this email in error or without authorization, please delete the email from your system and notify us immediately by sending us an email. If you need any further assistance, please send a message to he...@artefact.com.

Andrew Limn

unread,
Feb 4, 2021, 1:00:42 PM2/4/21
to Chrome UX Report (Discussions), jor...@creativemarket.com, Chrome UX Report (Discussions), Gilberto Cocchi, Andrew Limn
Hey Jordan,

As you say that would be lab data then, that's a shame to hear. I wonder then in this case if it's perhaps not the image format that's causing the delay, but maybe other prioritised assets get loading before it?

Good luck with finding the fix,

Andy

Jordan Barber

unread,
Feb 4, 2021, 1:07:37 PM2/4/21
to Chrome UX Report (Discussions), Andrew Limn, Jordan Barber, Chrome UX Report (Discussions), Gilberto Cocchi
Thanks!

Interesting you say that - I just posted a message to my team that I'm going to move onto optimizing assets higher in the waterfall.

Best of luck to you,

Jordan

Gilberto Cocchi

unread,
Feb 5, 2021, 8:47:39 AM2/5/21
to Jordan Barber, Chrome UX Report (Discussions)
Hi Jordan, glad to help if I can.

When you mentioned the "Google is looking at that fallback image to judge LCP" this raised a doubt to me, do you mind if I clarify that the Field CrUX data is not Google considering different logics etc.

The Field data comes from Chrome UX Report which is a representation of a proportion of your users Chrome real browser population.
You can find more information about how it works here: https://developers.google.com/web/tools/chrome-user-experience-report

If you made a change you may need to wait a couple of days or weeks to see the change, for example in PageSpeedInsights the Field data is coming from the last 28 days data timeframe on Real Chrome Traffic.

Gilberto



Reply all
Reply to author
Forward
0 new messages