Improving Core Web Vitals on an image-heavy business website

Let's imagine a business that has to show its work: an interior fit-out company, a photo studio, a practice with rooms meant to impress. The website has a large hero image, twelve reference photos, an embedded video, a map section, a booking widget and a cookie banner. Each of these elements makes sense on its own. Together they make a page that feels smooth on the developer's machine and noticeably stutters on a three-year-old mid-range smartphone on a mobile network.

This is a typical starting point, not a description of a single case. If you test the site on an office PC with fiber, you won't see the problem. If you open it on the train, you wait for the hero image, watch text jump, tap a menu and experience a delay. This experience is the actual subject of Core Web Vitals: Google condenses it into three metrics that describe loading, responsiveness and visual stability.

This expert analysis describes how we would examine and organize such a starting point. It contains no measurement series from a client and no promises about rankings. It shows mechanisms, trade-offs and an order of work that can be transferred to many image-heavy sites.

A sober attitude matters to us here. Speed is not an end in itself, and not every site has to reach every threshold. A business with twenty visitors a day has different priorities than a portal with thousands. We first ask whether visitors are failing on load time today, and only then how much effort is worth spending on it. Sometimes the answer is that three targeted interventions are enough and the rest is a matter of taste.

Core Web Vitals consist of three measures. Largest Contentful Paint (LCP) measures when the largest visible element in the initial viewport has finished rendering, usually the hero image or a large headline; a value of up to 2.5 seconds counts as good. Interaction to Next Paint (INP) describes how quickly the page visibly responds after an input; up to 200 milliseconds is good. Cumulative Layout Shift (CLS) adds up unexpected layout shifts; up to 0.1 is good.

On image-heavy sites, several causes come together. The hero image was uploaded as a raw export and weighs several megabytes. Web fonts load late, so the text first appears in a fallback font and then jumps. Third-party scripts for tracking, maps, chat and booking compete for the same connection and the same main thread. The cookie banner pushes content down after the fact or covers exactly the element that counts as the LCP.

On top of that comes the front-end load: those who use a framework often ship more JavaScript than the page needs for reading. The browser has to load, parse and execute it before menus and forms respond reliably. This hydration phase is a frequent but rarely recognized cause of poor INP values.

The causes also reinforce each other. A heavy hero image occupies the connection while scripts claim bandwidth and processing time in parallel. A font swap that would hardly be noticeable on its own adds up, together with a late-loading banner, to a noticeable jump. That is why fixing a single point rarely brings a breakthrough, while three small interventions in the right place often achieve more than one large rebuild.

The most common mistake starts with a single Lighthouse run. Lighthouse and the lab section of PageSpeed Insights simulate a page visit under defined conditions. That is valuable because changes can be compared reproducibly. But it is a model: device, network and location are assumed, and no real interaction takes place. A lab value for INP therefore does not exist in the same way; Total Blocking Time serves as a stand-in.

Field data comes from real visitors. The Chrome User Experience Report (CrUX) collects it, and Search Console shows it separately for mobile and desktop and groups URLs with a similar structure. This field picture is what counts for assessing Core Web Vitals, over a rolling period of around 28 days. That also means an improvement is not visible the next day.

We would therefore keep the two sources separate. The field tells you whether a problem exists for real people and on which page types. The lab tells you why, and whether a change is moving in the right direction. Small sites with little traffic sometimes have no sufficient field data at all; then the lab remains, supplemented by your own measurement in the browser, as a provisional guide.

A practical example: the home page shows a good LCP in the lab, but not in the field. Possible explanations are visitors with slow connections, a cookie banner that only appears on the first visit and is missing in the test, or dynamic content depending on location. You only spot such differences if you look at both sides and deliberately make the lab more realistic, for example with a throttled network and an empty cache.

Performance work rarely fails for lack of knowledge, but for lack of order. An audit delivers thirty findings, and all of them seem equally urgent. We would sort them by two criteria: how strongly does the item affect one of the three metrics on the pages with the most traffic, and how much effort and risk does the change involve?

Images and delivery almost always come first, because they offer a large effect at manageable risk. Third-party scripts follow, where the question is whether the service is needed at all. Fonts and layout stability come next. Rebuilding the JavaScript architecture usually comes last, because it is expensive and only worthwhile if the cheaper steps are not enough.

A plugin or a performance service that applies optimizations automatically is often offered as an alternative. That can help on simple sites. On sites with a custom structure, however, it lacks the knowledge of which image is the LCP and which script is dispensable. We would use automation as a tool, not as a strategy.

One principle helps with the selection: first remove, then shrink, then defer, and only last speed up. A script nobody needs causes no more cost. An image that is allowed to be smaller loads faster than any cache rule. What is necessary but not immediately goes behind the first interaction. This order saves effort and leads to solutions that still work in two years.

On image sites, LCP is usually about a single element. Three questions decide: how large is the file, when does the browser discover it, and how long does the server take to respond? An image embedded as a CSS background or loaded later via JavaScript is found late by the browser. As a real image element in the markup, flagged with high priority, the download starts earlier.

When it comes to format, modern alternatives are worth a look. WebP and AVIF compress considerably better than JPEG at comparable quality; AVIF needs more computing time for encoding, while WebP is more broadly proven. A sensible approach is to offer both through a picture element and keep JPEG as a fallback. The quality level remains decisive: photos must still look high-quality in the end, and no metric justifies muddy reference images.

Responsive images are the second lever. With srcset and sizes, a smartphone gets a file of suitable width instead of the desktop version. All images below the visible area load lazily, the hero image does not: it must never be given loading="lazy", otherwise the LCP is artificially delayed. And every image gets a width and height so that the browser reserves the space.

The choice of subject also plays a part. A photo with a lot of fine structure, such as wood grain or tile joints, compresses less well than a calm surface. Sometimes a different crop brings more than any setting in the encoding software. For the initial viewport, it is worth choosing a subject that works on small screens and not just in widescreen format; that way there is no need to ship huge files.

An optimized image is of little use if the server takes a long time to respond. This is where hosting, caching and a content delivery network (CDN) come into play. A CDN serves static files from locations close to the visitor; for a site that mainly reaches customers in German-speaking countries, the gain is smaller than for an international audience, but it exists. Caching is often more important: images, fonts and scripts with versioned names can stay in the browser for a long time, while HTML is cached briefly or not at all.

We review third-party scripts one by one. What function does the script serve, who evaluates the data, and can it run later or on click? A map can be shown as a static preview image that loads the interactive version only after a tap. A chat widget may start after the user's first interaction. This pattern reduces the load for visitors who never open the service, and at the same time fits privacy-friendly consent.

With code, what counts is what the browser has to execute at startup. Pages that consist mainly of content need hardly any client-side logic. Server-side rendering, smaller bundles, split code and interactive areas that are only hydrated when needed shorten long tasks on the main thread. This feeds directly into INP, because the browser no longer makes inputs wait behind computations.

A check that has proven its worth: start a recording in the browser's performance panel, tap a menu or form, and look for long tasks. If a block of several hundred milliseconds shows up there, the cause is usually a single script or component that does too much at startup. Such findings are concrete and can be fixed in a targeted way, instead of vaguely demanding “less JavaScript”.

The cookie banner is a special case because it combines two interests that clash: legal requirements and loading behavior. If it is inserted into the text flow after the fact, it shifts everything and drives up the CLS. It is better to reserve space or build it as an overlay that does not move the content. In addition, the banner should not be the largest visible element, otherwise the LCP measures the banner instead of the hero image.

With web fonts, the font swap can never be prevented entirely, but it can be softened. Few font styles, self-hosting on the same server and preloading the most important file shorten the wait. With font-display you control what is visible in the meantime, and modern adjustments to the fallback font keep line breaks almost identical. Then the jump stays unobtrusive.

Carousels and automatically rotating images are another case: they often load several large images although only one is visible, and interacting with them burdens the main thread. Here you should honestly ask whether the gallery needs this mechanism. A calm grid with lazily loaded thumbnails and a large view on click tells the same story with less load. It is a design question, not a purely technical one, and we would decide it together.

One last special case concerns videos. A video embedded from a platform often loads several hundred kilobytes of script when the page is opened, although hardly anyone plays it. A preview image with a play button that fetches the player only on click keeps the page light and shows the same visual. The video stays; only the timing of the load changes.

First, an honest word on ranking. Core Web Vitals are a signal within page experience, that is, one factor among many. Content that matches the search query, links and trust usually weigh more. A page with weak relevance does not climb because it becomes fast. Between two similarly strong pages, however, speed can tip the balance. Anyone who promises ranking jumps is selling more than can be proven.

The more reliable benefit lies with the visitor. A page that becomes visible quickly, stays stable and responds to taps loses fewer people before the first contact. This directly affects inquiries, calls and appointment bookings. How large the effect is on a specific site depends on industry, traffic source and starting state, and we do not quote percentages for it.

Measurement would work like this: in the Core Web Vitals report, Search Console shows whether URL groups move from “poor” or “needs improvement” to “good”, with a delay of a few weeks. PageSpeed Insights additionally provides CrUX values per URL. From a business perspective, what counts is a comparison of bounce behavior and contact inquiries before and after the changes, ideally over several weeks, so that seasonality and campaigns do not distort the picture.

What cannot be guaranteed is that all metrics turn green on every page. An embedded service the business needs can bring a remainder of load with it, and some audiences use weak devices. Then what counts is where the biggest friction lies and what can be fixed there. An honest interim assessment with open points is worth more than a polished overall grade.

The most common setback comes after the project. Someone uploads a new hero image in raw format, marketing embeds another script, an editor adds a gallery with fifty images. None of these actions is meant wrongly, and each can worsen the metrics. Improvements without safeguards are therefore only a snapshot.

Performance budgets make the limits visible. A budget defines how large images, scripts and the total page weight may be at most, or which lab values must not be undercut. In a build pipeline, such checks can be automated so that a deployment gets flagged before it goes live. In addition, image processing at upload ensures that editors do not bring oversized files into the system.

On top of that comes a simple routine: a look at Search Console once a month, a short check after major changes, and a list of permitted third-party scripts with responsible owners. This discipline is less spectacular than a rebuild, but it prevents the same problems from returning after a year.

Anyone who wants to improve Core Web Vitals needs an honest inventory first and measures only afterwards. The first step costs nothing: open Search Console, look at the Core Web Vitals report and check which page types stand out on mobile devices. After that, a PageSpeed run for each flagged page gives the first hints.

For image-heavy company sites, the order is usually clear: hero image and image delivery, then third-party scripts, then fonts and layout, and code last. Each step can be checked individually, and each brings something even if the next one is never needed. The goal is not a top grade in the testing tool, but a page that visitors can use without friction.

If you would like to know where your site stands, we will look at your field data together and name the three levers with the best ratio of effect to effort. The result that nothing urgent needs doing is part of that, too.