You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While optimizing our website, we stumbled about bad Lighthouse values for "Largest Contentful Paint (LCP) Element". The reason here is, that the <img> tag holds a 1280px width generated PNG file. The original uploaded PNG is a photo with transparent background (a special header image) and was offline optimized with a lossy PNG compression (170kb). Unfortunately, the ImageMagick/MagickImage lilbrary on the server only can use loss-less PNG compression, so the generated file for <img> has 700kb in file-size.
Lighthouse complains, that the file of this <img> source is too large, resulting in a bad LCP value. BUT: using a real browser web-debugger we can see, that the <img> src is never loaded for any responsive screen-size (means: this file does not matter at all).
It seems, Lighthouse doesn't simulate real browser behavior here, but instead it scans the DOM and assumes the src of the <img> as the LCP candidate.
Digging around a bit we found this information: "Even though the <picture> element provides multiple <source> options, the <img> tag inside <picture> is still seen as the default fallback-image by browsers" and " Lighthouse prefers srcset over <picture> and <source> elements when deciding the LCP element."
So a possible improvement (or solution) for the described problem would be, to refactor the Media/Rendering/Image partial and only use <img> with srcset instead of the current <picture> element:
Because this syntax is not very intuitive, I personally prefer the "clean" <picture> and <source> structure. Also from Accessibility (ARIA) perspective the current implementation might be more useful, but not sure about that. We just want to open the discussion here in case someone else having similar problems, so we can collect the pros/cons for both variants if this is helpful. Otherwise feel free to close it to stay with the current solution as final decision.
The text was updated successfully, but these errors were encountered:
While optimizing our website, we stumbled about bad Lighthouse values for "Largest Contentful Paint (LCP) Element". The reason here is, that the
<img>
tag holds a 1280px width generated PNG file. The original uploaded PNG is a photo with transparent background (a special header image) and was offline optimized with a lossy PNG compression (170kb). Unfortunately, the ImageMagick/MagickImage lilbrary on the server only can use loss-less PNG compression, so the generated file for<img>
has 700kb in file-size.Lighthouse complains, that the file of this
<img>
source is too large, resulting in a bad LCP value. BUT: using a real browser web-debugger we can see, that the<img>
src is never loaded for any responsive screen-size (means: this file does not matter at all).It seems, Lighthouse doesn't simulate real browser behavior here, but instead it scans the DOM and assumes the src of the
<img>
as the LCP candidate.Digging around a bit we found this information: "Even though the
<picture>
element provides multiple<source>
options, the<img>
tag inside<picture>
is still seen as the default fallback-image by browsers" and " Lighthouse preferssrcset
over<picture>
and<source>
elements when deciding the LCP element."So a possible improvement (or solution) for the described problem would be, to refactor the
Media/Rendering/Image
partial and only use<img>
withsrcset
instead of the current<picture>
element:Because this syntax is not very intuitive, I personally prefer the "clean"
<picture>
and<source>
structure. Also from Accessibility (ARIA) perspective the current implementation might be more useful, but not sure about that. We just want to open the discussion here in case someone else having similar problems, so we can collect the pros/cons for both variants if this is helpful. Otherwise feel free to close it to stay with the current solution as final decision.The text was updated successfully, but these errors were encountered: