Core Web Vitals for Fleet and Hire Websites, Explained Properly

Core Web Vitals are three measurements of how a page feels to the person using it: how long until the main thing appears, how fast the page answers a tap, and how much it jumps around while loading. Google documents all three on web.dev with current thresholds, and describes page experience as one of the signals its ranking systems consider alongside content quality. For a fleet or commercial hire site, the more direct argument is simpler: the site is read on a phone in a yard, on a connection that is often poor, by someone who is comparing you to two competitors. A page that takes six seconds loses that comparison before it has said anything.

What each metric actually measures

The names are unhelpful, so it is worth restating them in terms of what a person perceives.

Largest Contentful Paint is the moment the biggest piece of content in the viewport finishes rendering. On a fleet home page that is usually a photograph of a vehicle. On a depot page it is often a map or a heading. web.dev documents it as the metric for perceived load speed, because the largest element appearing is what most people read as the page having arrived.

Interaction to Next Paint replaced the older responsiveness metric and measures the delay between a person interacting and the page visibly responding. Tapping a vehicle class filter and watching nothing happen for half a second is exactly what this measures. web.dev documents it as an assessment of overall responsiveness across the whole visit, not just the first interaction.

Cumulative Layout Shift measures how much visible content moves position unexpectedly during the life of the page. The familiar version is reaching for a phone number and having a late-loading banner push it down so the tap lands on something else. web.dev documents it as a measure of visual stability.

Why three and not one

They fail independently. A page can appear instantly and then refuse to respond to a tap because a script is monopolising the main thread. A page can be perfectly responsive and still shove its own content around for three seconds. Optimizing one does not fix the others, and a site that looks fine on a single-number score can be failing badly on the one that actually affects its buyers.

The hero photograph problem

On most fleet and hire websites, the Largest Contentful Paint element is the hero image, and it is usually doing at least three things wrong.

It is the wrong size. A photograph exported at the width of a desktop display and then served unchanged to a phone means the device downloads several times the pixels it can use, on the connection least able to afford them.

It is in the wrong format. A photograph saved as a legacy format is substantially larger than the same photograph in a modern one at equivalent quality. Serving modern formats with a fallback is a solved problem and costs nothing at runtime.

It is lazy-loaded. Lazy loading is correct for images below the fold and actively harmful for the image that is the first thing on the screen, because it delays the load until after layout. The hero image should be loaded eagerly and, where possible, given a high fetch priority.

Fixing it in order

Resize first, because it is the largest single saving. Convert second. Then check the loading attributes. Then, only then, consider whether the image needs to be there at all. A surprising number of fleet hero images are decorative photographs of a vehicle that the buyer has already seen a thousand of, sitting in front of the text that would have persuaded them. Removing it is a legitimate answer, and it is the fastest page you will ever ship.

The trap of the background image

Setting the hero image as a CSS background feels tidier and defeats several of the optimizations above, because the browser cannot discover it as early and the standard loading attributes do not apply. Where the image is content, put it in the markup. Reserve background images for texture that genuinely does not matter if it arrives late.

Third-party scripts, and the honest accounting

The second consistent offender is the set of scripts nobody remembers adding.

A map embed on every depot page. A chat widget. A tag manager that loads analytics, a heatmap tool, a remarketing pixel and an A/B testing script. A social feed. Each was added for a reason, each looked small, and each was measured alone. Together they routinely account for most of the main thread work on a page, which is what Interaction to Next Paint measures.

Audit by cost, not by count

The useful exercise is not counting scripts, it is asking what each one returns. A heatmap tool nobody has opened in eight months is pure cost. A remarketing pixel for a campaign that ended is pure cost. A chat widget that produces two conversations a month, on a page that loses readers to slowness, may well be net negative.

Load late what can be late

Whatever survives the audit should load after the page is usable, not before. Analytics does not need to run before the content renders. A chat widget can load on first interaction or after a delay rather than on page load. A map can be replaced with a static image and a link that loads the interactive version only when someone asks for it, which on a depot page is the right trade almost every time.

The map embed specifically

Depot pages are the worst case because the map is genuinely useful and genuinely expensive. The pattern that works is a lightweight static representation, with the address as real text and a link that opens directions in the visitor’s own map application. That is what most people want anyway: they are not going to study your embedded map, they are going to navigate to the depot using the application already on their phone.

Layout shift is the cheapest fix

Cumulative Layout Shift is almost always caused by content loading into space that was not reserved for it, and the fix is to reserve the space.

Set explicit width and height attributes on every image, so the browser can allocate the box before the bytes arrive. Give embeds and iframes an explicit aspect ratio. Reserve space for anything that appears conditionally, such as a cookie banner or an availability notice, so its arrival does not push the page. Load fonts in a way that does not swap between wildly different metrics, and set a fallback stack whose dimensions are close to the web font.

None of these require a rebuild. They are attributes and a handful of CSS rules, and they eliminate the single most irritating failure mode a buyer experiences: reaching for a phone number and hitting something else.

Lab data and field data are different things

This distinction causes more wasted effort than any other part of the subject.

A lab tool loads your page once, on a simulated device, on a simulated connection, from a single location. It is excellent for diagnosis: it will tell you which element is the Largest Contentful Paint, what is blocking the main thread, and which images are oversized.

Field data records what real visitors on real devices actually experienced. It is the only source that reflects the fact that your buyers are on mid-range phones in areas with variable coverage, rather than on the reference device the lab tool simulates.

Use each for what it is for

Decide whether you have a problem using field data. Diagnose the problem using lab tools. Verify the fix in the lab, then confirm it in the field over the following weeks, because field data is collected over a trailing window and will not move the day you deploy.

A common and expensive mistake is chasing a lab score upward past the point where field data has already shown the page is fine for real visitors. The score is a proxy. The buyers are the thing.

Mobile is the version that counts

Google documents mobile-first indexing, which means the mobile version of the page is the one primarily used for indexing and ranking. For a fleet site that alignment is convenient, because mobile is also where the page is genuinely read.

Test on a mid-range device rather than the newest one in the office. Test on a throttled connection rather than office broadband. Test in daylight, which is where the contrast decisions stop being theoretical. The gap between how a fleet website performs in a design review and how it performs in a depot yard is where most of the lost enquiries live.

What to check on the phone specifically

Whether the primary call to action is visible without scrolling. Whether the phone number is a link that dials. Whether tap targets are large enough to hit without precision. Whether anything moves after the page appears to have loaded. Whether the enquiry form can be completed one-handed. None of these are Core Web Vitals, and all of them determine whether the visit produces anything.

Fonts, and the cost of a nice one

Typefaces are the quiet contributor to all three metrics, and the failure is rarely the font itself.

A web font that is loaded from a third-party host adds a connection to a domain the browser has not spoken to yet, before it can even request the file. If the font is the thing the Largest Contentful Paint element is set in, the text cannot paint until that round trip completes. If the fallback has different metrics, the swap moves every line of text on the page, which is layout shift.

The practical rules

Load as few families and weights as the design genuinely uses. Three weights of one family is a design decision; nine weights of three families is an accident. Preconnect to the font host so the connection is opened early rather than discovered late. Use a display strategy that shows fallback text immediately rather than hiding it, so a slow font delays the styling and not the reading. Pick a fallback stack whose proportions are close to the web font, so the swap is a change of character rather than a change of layout.

When to self-host

Self-hosting removes the extra connection entirely and puts the font on the same fast path as the rest of the site. It is worth doing when the font license allows it and when the design depends on the face arriving quickly. It is not worth a licensing argument for a face used in one heading.

Measuring without guessing

It is worth being concrete about how to tell whether any of this worked.

Take a baseline before changing anything, on the three page types that matter: the home page, a depot page and a vehicle class page. Those three have different failure profiles and a fix that helps one can miss the others entirely. Record which element is the Largest Contentful Paint on each, because that is the number that tells you where to aim.

Change one thing at a time where you can. The temptation on a slow site is to ship eight fixes together, which works but teaches you nothing about which of the eight mattered, and next time you will do all eight again whether or not they were needed.

Then wait. Field data is collected over a trailing window, so the day after a deployment it still largely describes the old page. Judging a fix on day one produces the wrong conclusion in both directions: a real improvement looks like a failure, and a regression looks fine.

The one number worth reporting internally

If you have to summarise this for someone who does not want to discuss metrics, use the proportion of real visits that had a good experience on all three, on mobile. It is a single percentage, it is grounded in actual visitors rather than a simulation, and it moves for real reasons. It also resists the most common misuse of a performance score, which is presenting a lab result from a desktop run as though it described the people in the yard.

The trade nobody states out loud

Almost every performance decision on a fleet website is a trade between something a stakeholder asked for and something a buyer experiences, and the reason sites end up slow is that only one of those two parties is in the room.

The marketing manager asked for the heatmap tool. The sales lead asked for the chat widget. Someone senior asked for the video on the home page. Each request was reasonable and each was granted by a person who had no way to price it, because the cost lands on a buyer nobody in the meeting has met, on a phone nobody in the meeting is holding.

Put a number on the request

The fix is not to refuse things. It is to make the cost visible at the point the request is made. Before a third-party script is added, measure the page with and without it on a throttled mobile profile and report the difference in the same sentence as the benefit. A chat widget that costs a second and a half of responsiveness may still be worth it, but it should be chosen knowing that, not by default.

Give the site a budget

The durable version of this is a performance budget: a stated ceiling for page weight and for main thread work that any new addition has to fit inside. When something new arrives and the budget is full, the question becomes which existing thing it replaces. That is a much healthier conversation than the usual one, in which everything is additive and the page gets slower by a small amount every quarter until someone notices it is bad.

A budget also makes the guarantee meaningful. A speed commitment that is measured once at launch is a screenshot. One that is enforced on every change is a property of the site.

What to change first

If you do nothing else, do these four, in this order.

First, fix the largest image: correct size, modern format, explicit dimensions, eager loading if it is above the fold. On most fleet sites this alone moves Largest Contentful Paint into a different category.

Second, audit third-party scripts and remove what nobody uses. This is a decision, not a development task, and it is usually the second largest saving available.

Third, set dimensions on everything else that loads, and reserve space for anything conditional. Layout shift goes away.

Fourth, defer what remains. Analytics after render, chat on interaction, maps on request.

Keeping it fixed

Performance regresses. It regresses because someone adds a pixel for a campaign, or uploads a photograph straight from a camera, or embeds a video in a blog post. A site that was fast at launch and is slow eighteen months later did not decay, it accumulated.

The practical defence is that adding something to the site is a routine, reviewed change rather than an unmonitored one, and that images are processed on the way in rather than uploaded raw. That is the argument for a managed build: on the plans we run, the speed guarantee is a term rather than a launch-day screenshot, and the features page sets out what that covers. If you are weighing a rebuild of an existing site, the fleet website redesign page describes how the migration protects what is already working while fixing what is not.