Persistent Poor LCP (Largest Contentful Paint) Score in Lighthouse
We've been optimizing a website to try and improve our PageSpeed/Lighthouse scores. The one problem is a very poor Largest Contentful Paint score (driven especially by render delay)
and for the hero image on our page:
<img src="https://res.cloudinary.com/dbzo4mz7l/image/upload/f_auto,q_auto,w_1704/v1/…" alt="pest control in astoria" height="100%" width="100%" style="object-fit:cover;">
https://res.cloudinary.com/dbzo4mz7l/image/upload/f_auto,q_auto,w_1704/v1/ecology/hero_img/astoria_ditmars_queens_hero_QN01
We suspect we may be using the wrong URL convention (i.e., inserting the "v1" as a separate subdirctory), or adding the wrong sequence of modifiers (f_auto,Q_auto,w_1704).
Note: on one page we use three different delivery URL conventions:
1: v1/{account}/plain_text_url
2: v1/{update date}/asset_file_name
https://res.cloudinary.com/dbzo4mz7l/image/upload/f_auto,q_auto/v1/20230211/bed-bug-exterminator-in-astoria-QN01
3: {link based on current clodinary asset number}
All seem to work but we're wondering if the format and/or inconsistency could be the cause of the rendering delay.
For example, link style #3 seems to trigger a "cache-busting" effect: https://support.cloudinary.com/hc/en-us/articles/360001208732-CDN-Invalidations-URL-conventions-invalidated-for-removed-or-replaced-assets
Any help for best practices on constructing cloudinary URLs to prevent excessive LCP and render scores?
Are we inadvertently causing the cache to reset (bust) by using link style #3?
Answers
-
Hi David. I replied to you via our ticketing system just now, but I wanted to post the reply here too in case it benefits any other users in the future:
Google's PageSpeed Insights is showing you how long the largest content took to appear, but it's not necessarily saying that the image file itself loaded slowly - depending on how and when you're adding it to the DOM, and what else is happening on the page at the same time, the LCP time could be slow even if the file itself loads very quickly when requested.
For example, when I tested the page myself, on the mobile tab, it lists the LCP time as 2,940 ms, but of that 49% was "Load Delay", which isn't related to how long it took Cloudinary to respond after we received a request for the asset (that's "TTFB"), or how long the client took to receive the file from Cloudinary (that's "Load Time")
To address the delay, there are some recommendations on this Chrome site which may help: . You may also want to add additional transformations to resize the dimensions of your assets in order to ensure they load quickly.
I would also recommend adding a preconnect meta tag if there isn't one already, and to check how your DOM is being built to ensure that any libraries responsible for making that image appear are prioritised / are earlier than other less-important content, and that any content loaded before the image is truly needed (e.g. using minimal JS libraries or loading them later).
I hope this helps. Please let me know if you have any further questions.
Kind regards,
-Danny
0 -
Thanks Danny. One additional thought is about the mismatched delivery URLs, especially with the comment about "cache-busting" (where the style of delivery URL would cause cloudinary to reset the cache. Is that something we should worry about?
0 -
Hi David,
You can use the version number or not. It's up to you. It is the timestamp of when the asset was uploaded to your account. If you omit the version number, the delivery will still work. For example, here is our sample image taken from the demo account:
https://res.cloudinary.com/demo/image/upload/v1610625835/sample.jpgHere is the same image, with the version number removed from the URL:
https://res.cloudinary.com/demo/image/upload/sample.jpgYou can refer to the following documentation for additional information on versions:
https://support.cloudinary.com/hc/en-us/articles/202520912-What-are-image-versionsI hope this helps. Let me know if you have any questions.
Kind regards,
Tia
Helpful Links For You
💬 Share questions, connect with other users in our Cloudinary Community forums and Discord server!
🧑🎓 Join our Cloudinary Academy for free courses, workshops and other educational resources.
📄 Read our documentation for in-depth details on Cloudinary product features and capabilities
📰 Check out the Cloudinary blog for the latest company news and insights0 -
Can you please reply to the specific comment about "cache-busting" since I feel that could be relevant here. In the article you cited, it says:
"Though you can request that Cloudinary's CDN cache is invalidated for an asset when you overwrite it, the old asset may still be stored in caches outside Cloudinary's control such as browser caches, ISP, corporate, or other third-party caches.- By storing the version for each asset, and including the asset's current version when building the URL, you can ensure that users of your site or application will request the asset again when the version number changes, bypassing any third-party caches of the previous asset URL.
So, by using the delivery URL with the specific version number, are we in fact directing cloudinary to force the browser to redownload the entire image upon each page view?
We're trying to completely rule out Cloudinary as the source of excessive load time under the LCP measurement.0 -
Hi David. Apologies for not addressing that point directly.
Using the version number in a URL requests a specific version of that asset, but it doesn't force the asset to be regenerated each time a request is made. Imagine for instance you run a shopping site with HeroImage.png at the very top, promoting a winter sale. If you replace this asset in Cloudinary with a new spring graphic, but don't modify the URL, new visitors to the site would see the spring graphic, but older visitors may still see the winter graphic, depending on their browser's cache settings.
By using version numbers in the delivery URL, we effectively prevent this behaviour, because the winter version and spring version of HeroImage.png would have distinct version ID, and thus, unique URLs.
I appreciate there may be some ambiguity in the "if you're using option 3" paragraph, but I can assure you, using a version in the URL won't force the browser to refresh the cache on every single request.
Kind regards,
-Danny
0 -
OK, thanks.
We've been running a few tests on other websites using Cloudinary to host images. These websites also exhibit significant render and/or load delay under LCP performance:
0 -
Hi @david,
As Danny mentioned, optimizing images can significantly enhance website performance and overall score.
If you're looking for more detailed insights into which specific URLs can be improved and which transformations could benefit your site's loading speed, I highly recommend using our WebSpeed Test Tool.Best regards,
Tamara0
