Image optimization for faster websites, and what it moves

The request arrives in a familiar shape. The site feels slow, someone ran a page speed tool, the report said to serve images in modern formats and defer offscreen images, and now there is a ticket. Fair enough. The images on most business sites are genuinely too big.

What goes wrong is the next step. A week gets spent converting everything to WebP, the score moves four points, and the page still feels slow on a phone. That outcome is predictable from Google’s own documentation, and the same document tells you which sites it will happen to.

The threshold you are optimising against

Largest Contentful Paint measures when the biggest thing in the viewport finishes rendering, and on a marketing page that is almost always an image. Google’s guide to optimising LCP sets the bar: sites "should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits", with anything above 4.0 seconds counted as poor.

The 75 per cent matters as much as the 2.5 seconds. It is a percentile across real visits, not a lab score, so a fast result on your own laptop on office wifi tells you very little. We have written separately about what Core Web Vitals do and do not buy commercially, and the short version is that the thresholds are worth meeting and the revenue stories told about them are mostly unfalsifiable.

LCP has four parts, and images sit in one of them

This is the part that decides whether an image project pays. Google breaks LCP into four consecutive sub-parts and publishes a rough share each one should take.

Google is careful to call these guidelines rather than rules, and warns against turning them into millisecond budgets, because the shares are only meaningful relative to each other. The useful move is to find which part is oversized on your own page before touching anything.

If time to first byte is eating the budget, image optimisation is the wrong project. That is a server, a plugin stack or a hosting decision, and the difference between those is what static site versus WordPress performance is actually about.

Never lazy load the image at the top of the page

The single most common self-inflicted wound in this area comes from following half of the page speed advice. A tool says to defer offscreen images, someone adds loading="lazy" to every image on the site, and the hero image is now deferred too.

Google states it without hedging: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay." The attribute makes the browser wait until layout confirms the image is in the viewport before requesting it, which is exactly the wrong behaviour for the one image already in the viewport.

So the rule is narrower than the tooling implies. Lazy load everything below the fold. Never lazy load the thing at the top.

fetchpriority, and the limit Google puts on it

The counterpart is fetchpriority="high" on the image likely to be the LCP element. It tells the browser to pull that resource early rather than treating it as one image among many.

The documentation then adds the caveat that most blog posts about this attribute leave out: setting high priority on more than one or two images stops helping LCP. Priority is relative, so marking everything important marks nothing important. There is also a useful inverse, fetchpriority="low", for images that sit early in the HTML but are not visible at startup, hidden carousel slides being the standard example.

Formats, and the size that actually ships

With the above in place, the format work is worth doing. Google recommends modern formats such as AVIF or WebP, compressing, and reducing the image to its optimal dimensions. The dimensions part is usually the bigger win and the one that gets skipped, because a 3000 pixel wide photograph displayed in a 600 pixel column is wasting most of its bytes no matter how it is encoded.

Two practical notes from the same page. An image CDN can cut both distance and file size without anyone hand-exporting anything, and serving images from the same origin as the HTML avoids an extra connection cost. If a CDN is already in the stack for other reasons, the second-order effect on bandwidth bills is worth a look, and we went through where those bills actually come from in reading a cloud hosting bill by line item.

Alt text belongs in this pass too, because this is the one time somebody is editing every image on the site. The requirements it needs to meet are in what accessibility compliance actually asks of a business website.

The background image the browser cannot find

A hero set as a CSS background is a special case worth knowing, because it fails quietly. The browser’s preload scanner reads the HTML before the stylesheets finish, so an image referenced only from CSS, or only from JavaScript, cannot be discovered at that point. It gets requested late and the resource load delay row in the table above grows.

Google’s fix is a <link rel="preload"> with as="image" and a high fetch priority, and its stated goal is that the LCP resource starts loading at the same time as the first resource on the page. For images written in the HTML, the equivalent requirement is that the src or srcset is present in the initial markup rather than assembled by a script.

The order that pays

• Find which of the four sub-parts is oversized on your own pages, using field data rather than a lab run.
• Remove loading="lazy" from anything in the first viewport, then check nothing else above the fold is deferred.
• Put fetchpriority="high" on the one image that is the LCP element, and only that one.
• Preload any hero that is referenced from CSS or JavaScript rather than from the HTML.
• Resize to the dimensions actually displayed, then convert to AVIF or WebP and compress.
• Re-measure in the field. If the number did not move, the bottleneck was never the images.

The commercial read on all of this for an Arabic-language site, including what Google says about how much page experience affects ranking, is covered in KF Agency’s Arabic article on how fast a site is actually supposed to load, which is in Arabic and works from the same published thresholds.

Honest limits

Google says the bottleneck is usually elsewhere. The same guide notes that its research indicates load duration is often not the main bottleneck, and advises checking real-user data before focusing there. That is an unusual thing for a performance guide to admit, and it is the reason this note leads with the four sub-parts instead of with formats.

Smaller files do not always mean a lower LCP. The documentation is explicit that shrinking a file can simply move the saved time into element render delay, if the element is still being held back by other code. The bytes went down, the metric did not, and the report looks like a failure of the image work when it is a rendering problem.

None of this is about perceived speed. LCP is one moment on a timeline. A page can clear 2.5 seconds and still feel slow because of layout shifting under a thumb or an interaction that takes half a second to respond. Those are different metrics with different fixes, and an image pass does not touch them.

We have not measured your site. Everything above is Google’s published guidance plus the pattern we see in the work. The one number that matters is which sub-part is oversized on your own pages, and nobody can tell you that from the outside.