I have a running site on Windows Server but my page score is not good because of Largest Contentful Paint.
I tried multiple solutions with img tag like
webp and avif format
trying to use less res image on small screen device with viewport
but both of them are not working.
this is fully about your HTML and front end, and has nothing to do with cfml or Lucee. Output your html and javascript in such a manner to tackle the issues.
Another point: Don’t always believe that much in all that scanning stuff. Keep the pareto principle. You always need to see the overall of those insights. Also, if you scan some sites of the homepages of the very same scanning and evaluation sites, they often get pretty bad results as well.
1 Like
While you’ve raised this in the lucee forum, you refer to images. We need to understand first WHAT components specifically are slow for your request, and it would help to know what web server you’re using.
On the first point, are you viewing some lcp report? Does it have a breakdown of the component parts of the rendered page? If not, have you simply looked at your browser dev tools feature (they all offer one) and its network tab, to view the time taken to serve each component in a request (image, js file, css file, the original cfml file requested, if any, etc.) What is proving to be slow? It could be images, it could be a cf request.
To the second point, depending on what web server you’re using and how it’s configured, even an image request could be passed to lucee (technically tomcat) to process. It would be important to know what web server is serving any slow element, in order to identify why it’s slow.
There are even known issues with the AJP configuration of Lucee/tomcat that can impose an unexpected fixed delay on each document requested that way (which won’t happen for such static files if instead a web server like apache, iis, or nginx is serving them).
1 Like
Ah, Andreas and I were writing at the same time. While I’m writing again, I’ll add also for the Op that it may help to consider the ideas and suggestions for addressing lcp issues at the substantial resource here:
UPDATE : Oddly, once I submitted this comment the preview for that url shows as foreign characters (Chinese at first, then Vietnamese as I came to edit and add this paragraph. I can only suspect some caching issue for the way the underlying discourse engine here works to show that preview.
Anyway, the page appears to be written natively in English when I visit it! 
Here’s the url without the protocol: web.dev/articles/optimize-lcp. Perhaps it’s multilingual and even with that url will appear in other languages to suit the locality of the reader.
2 Likes
Just to add some insight, I did a lot of experiments about this a while back when I was optimizing my own framework I use for some of my webpages.
The LCP is not just the image resolution and sizes. It is a metric that shows how long the browser itself needs to paint (reender) the content to the visible area of the browser. Developers often just forget that many times its not just about images and image resolution. If you have some width and realative heights or what ever in your html, it might need to the latest html container to start calculating… or even worse, some of the top parts widths/heights definition of the html is somewhere in a separate file, and the information needs more time to load, or even worse, you do some fancy JS doom manipulation at the bottom of your page on the final load, and nothing shows up until your page is fully loaded, and your browser needs to make several calculations until it can start painting. You need to start from scratch and just start from an empty html body and you begin adding your stuff step by step until it starts breaking the good metrics. good luck.
1 Like
@carehart It’s the ?hl=vi url param appended to your url that makes the page display in Vietnamese.
Thanks for trying to help, Kenric. But no, the link as I’ve pasted it in that comment does NOT have that query string. Indeed, it has none. Here (without the protocol) is exactly what’s there:
web.dev/articles/optimize-lcp
And I didn’t create a link there. I literally just pasted the url in the body of the reply.
So again it must be this discourse service putting that qs when viewed for some reason, as part of i18n/l10n–though it seems somehow mistaken. (I’ll remind you that I’d said the first time I previewed it, it showed in Chinese.)
Anyway, there’s the link above, if it may help anyone. I’ll not remove the protocol in the original note, so that readers of these subsequent comments have context. But I will repeat the url without the protocol in the update to that reply that I’d added.
I’d rather think about some of those nasty automatic language detections combined with geo-ip-location services. The battle to keep my browser talking “english” is getting harder every day. Some sites just keep loading language or redirecting me on behalf of my geo location, when I just want go keep on that English site 
Yep, Andreas. I appreciate that challenge–especially for you all in Europe or elsewhere. But to be clear I’m reading/writing this in the US. Again, it was so odd that as soon as I tried to preview the first reply, it showed Chinese. I took my chances that it might look different on posting it, but then it was Vietnamese.
But yep, I wondered if somehow the preview feature for the servers running Discourse (underllying this forum) might have themselves been running from either locale, leading to the confusion for us. Oh well. Again, those who hit the link will find it in English (again assuming they are set for an English locale).
1 Like
Thank you so much for your replies guys,
What I was trying to do render the image according to window size. I tried multiple approaches like picture tag
<picture>
<source media="(max-width: 799px)" srcset="elva-480w-close-portrait.jpg" />
<source media="(min-width: 800px)" srcset="elva-800w.jpg" />
<img src="elva-800w.jpg" alt="Chris standing up holding his daughter Elva" />
</picture>
But I liked the idea from @andreas to start with a simple template just want to confirm if anyone is facing the same issue.