svgrenderingpagespeed

Is there a way to reduce Largest Contentful Pain element Render delay for a very small svg image?

I have a static website that has a very small (9KB) svg image. When I run the Pagespeed Insight I get this:

enter image description here

as I said the SVG file size is only 9KB. I tried to convert the image to webp, which created a 40KB image but still had a long render delay of almost 2 seconds.

I only have this when Pagespeed insight tests on mobile, for desktop I don't get this long render delay and performance is very good.

Is there any solution to reduce the render delay?

UPDATE: here is the URL of the page: https://www.doradolist.com/

Solution

  • The render delay is not necessarily because the image format or size is causing it to take a long time to display. It more likely the page hasn't requested it to display. Espcially for very large values like that.

    This of the following scenario:

    <script>
  -- do lots of blocking work
</script>
<img src="hero.jpg">

    In this case the image will be discovered by the preload scanner and fetched earlier, but the blocking script will prevent it from being rendered.

    Another common pattern is from a client-side rendered app:

    <html>
<head>
  <link rel="preload" src="hero.jpg" as="image">
</head>
<body>
  <div id="app"></div>
  <script src="app.js"?</script>
</body>
</html>

    In this case the image is preload so downloaded nice and early. But it's not in the page at all but is presumably added by app.js. So the render delay is waiting for the client script to run.

    You need to look at how your LCP image is requested, and when it is added to the DOM and displayed, and anything in between that is slowing that down.

    EDIT after site was shared

    Well, it was exactly as I predicted!

    Near the top of you HTML you have this:

    <link rel=preload href=images/hero/hero-image.svg as=image>

    So the image is loaded nice and early - that's great.

    But the image isn't in the HTML at all and is added by this script:

    <script>
if(window.innerWidth<990){
  var img=document.createElement("img");
  img.src="images/hero/hero-image.svg",
  img.alt="hero-img",
  img.width=305,
  img.height=246,
  document.getElementById("heroImage").appendChild(img)
} else {
  img=document.createElement("img"),
  img.src="images/hero/hero-image.svg",
  img.alt="hero-img",
  img.width=500,
  img.height=300,
  img.loading="eager",
  img.decoding="async",i
  mg.className="ml-5 h-auto w-full",
  document.getElementById("heroImage").appendChild(img)
}
</script>

    And that script can't be run until all the CSS is loaded as shown in this waterfall, where the green FCP/LCP line at 1.5 seconds is well after the image had finished downloading at 1.1 seconds.

    Waterfall

    I can't really see anything else blocking this to explain the short gaps after the CSS has all downloaded, but does look like the browser CPU and main thread is busy processing all that CSS, and then the image so I think on the constrained simulated devices that Lighthouse uses for mobile that's just how long it takes to process that much CSS and images.

    And on that note I would say your real world experiences LCP (where your site visitors may not be using such constrained devices) is looking great!

    Real world experiences from Page Speed Insights

    So I really don't think you've anything to worry about here.

    If you can remove that JavaScript and have this in the HTML then there might be slight gains, but not much to be honest and probably more to be gained from looking at your CSS. And inlining the critical CSS will bring this forward a lot, but that can be quick complex to get right. But, as I say, as long as your real world experiences as measured by Core Web Vitals are so good I wouldn't stress too much.