Roofing Website Speed: What Core Web Vitals Mean on a Job-Site Phone

Core Web Vitals measure three things a visitor actually feels: how long until the page shows them something useful, how quickly it responds when they tap, and whether it moves under their finger while they read. For a roofing website the context that matters is that those three are being judged on a phone, outdoors, on a carrier signal, by somebody who has two competitors open in other tabs.

The three metrics, and what each one feels like

Google’s Core Web Vitals documentation defines the set and publishes the thresholds. It is worth understanding what each one corresponds to in the real world, because the names obscure fairly simple ideas.

Largest Contentful Paint

LCP is the moment the largest piece of content in the viewport has rendered: usually the hero image or the main heading. In plain terms, it is when the page stops looking blank. Google’s LCP documentation gives 2.5 seconds or faster as good, 2.5 to 4 seconds as needing improvement, and over 4 seconds as poor.

For a roofing site the LCP element is almost always a large photograph of a roof, which is exactly why this metric is where most of them fail. A camera-resolution image dropped into a page and scaled down by the browser can be several megabytes, and on a weak signal that is the whole budget spent on one picture.

Interaction to Next Paint

INP measures how long it takes for the page to visibly respond after a tap or a click, across the whole visit rather than just the first interaction. Google’s INP documentation sets 200 milliseconds or under as good and over 500 milliseconds as poor.

This is the metric that captures the feeling of a page that has loaded but is not ready: you tap the menu, nothing happens, you tap again, and then two menus open. It is almost entirely caused by JavaScript occupying the main thread, which is why it is the metric that most punishes a site assembled from a stack of plugins.

Cumulative Layout Shift

CLS measures how much the content moves around after it first appears. Google’s CLS documentation gives 0.1 or less as good and over 0.25 as poor.

The classic version is an image that loads late, pushing the paragraph you were reading down the screen. The expensive version, on a roofing site, is a banner or a cookie notice that appears a second after the page and moves the call button just as a thumb is coming down on it. That is not a cosmetic problem; that is a phone call you did not get.

The 75th percentile, and why it is the important part

The thresholds above are assessed at the 75th percentile of page loads. That is a deliberately demanding way to measure, and it is the part most conversations about site speed skip.

It means that being fast for most people is not the standard. Three quarters of real visits have to be inside the threshold, which forces attention onto the slower end of your audience: older phones, poor signal, rural coverage, somebody standing behind a building. For a roofing company that audience is not an edge case, it is the core case. Your buyer is very often outdoors on a compromised connection, because that is the situation that made them think about their roof.

Lab scores and field data are not the same thing

A great deal of confusion comes from treating a PageSpeed Insights performance score as the whole picture. It is not, and the tool itself distinguishes the two halves.

Lab data is a single simulated load under fixed conditions. It is repeatable enough to compare changes, and it produces the score people quote. It also moves around between runs, because simulation involves variability, which is why a score can drop three points with no change to the site.

Field data comes from real Chrome users visiting your site, aggregated in the Chrome UX Report. It describes what your visitors actually experienced, on their devices and connections. It is slower to react to changes, because it is a rolling window, but it is the number that describes reality.

When the two disagree, field data is the one that matters for the business and the one that matters for how Google assesses page experience. A high lab score with poor field data usually means the test conditions are kinder than your customers’ conditions, which for a roofing company is extremely common.

Where roofing sites actually lose the time

Four causes account for the overwhelming majority of slow roofing websites, and they are worth checking in this order.

Photographs

Roofing is a visual trade and the photographs are the proof, so nobody wants to hear that the images are the problem. They usually are, and the fix does not mean fewer or worse photos.

The specific failures are uploading straight from the camera at full resolution, serving the same enormous file to a phone and a desktop, using formats from a decade ago, and loading every image on the page immediately including the twenty in a gallery three screens down. A correctly handled photograph is resized for the device asking for it, compressed properly, served in a modern format, given explicit dimensions so it reserves its space before it arrives, and loaded lazily unless it is the one at the top.

That is six things, all of which should be automatic rather than a checklist somebody remembers. On a site where they are not automatic, they will silently stop happening the first time anybody uploads a photo in a hurry, which on a roofing site is constantly.

Third-party scripts

Chat widgets, tracking pixels, review badges, form embeds, heat maps, analytics, and a tag manager to load all of them. Each one is a request to somebody else’s server and, more damagingly, JavaScript executing on the main thread. This is the usual reason for a poor INP, because the page is busy running other people’s code when the visitor taps something.

The honest question for each one is whether anybody has looked at what it produces in the last six months. Roofing sites routinely carry three tracking scripts from two former agencies and a chat widget nobody monitors. Every one of those is costing every visitor time.

Page builders and plugin stacks

A visual page builder renders a layout by shipping a general-purpose system to the browser and letting it assemble the page on the visitor’s phone. That is a large amount of code to do something that could have been finished before the request was ever made. Add a slider plugin, an animation library, a form plugin and a gallery plugin, each with its own stylesheet and script, and the page is carrying several hundred kilobytes of machinery to display a paragraph and a photo.

This is the structural reason custom-coded pages are faster, and it is not a matter of one being better written. It is that one of them does the work once, in advance, and the other does it again on every visitor’s device.

Fonts

Web fonts are small compared to images but they sit directly in the path of text appearing. A font loaded without a fallback strategy means either invisible text while it downloads or a visible reflow when it arrives, and the second of those feeds CLS. Two families, a sensible fallback stack, and a display strategy that shows text immediately covers almost every real case.

The gallery problem, and how to keep the photos

Every roofing company wants a before and after gallery, and every roofing company’s gallery is the slowest page on the site. It does not have to be, and the fix does not involve deleting anything.

The failure is loading all of it at once. A gallery of sixty images, each one two megabytes, is over a hundred megabytes of requests fired at a phone the moment the page opens, even though the visitor can see four of them. Lazy loading fixes most of that on its own: images below the fold are not fetched until they are close to being needed, which is a single attribute rather than a plugin.

The second half is serving the right size. A thumbnail in a grid does not need the full-resolution file. Generating a set of sizes and letting the browser pick, rather than shipping one file to every context, routinely takes ninety percent off the weight of a gallery page without any visible difference.

The third piece is the lightbox. A full-screen viewer that ships a large JavaScript library to do what a link and a larger image could do is a bad trade on a page that is already heavy. Where a viewer is genuinely wanted, it should be small and it should load when somebody opens an image rather than when the page does.

Handled that way, a sixty-image gallery can open as fast as a text page, which matters because the gallery is often the page that convinces somebody. Losing it to a timeout is losing the argument you were about to win.

Where the time is spent before the page even starts

Everything above concerns what happens after the browser has the HTML. There is a chunk of time before that, and on a slow site it is significant.

The server has to be asked, has to decide what the page is, and has to answer. A site that builds every page on request, by querying a database and assembling a template, spends real time doing that on every single visit, and it spends more of it when several visitors arrive at once. A site whose pages were built in advance and are served as ready-made files from a network of locations close to the visitor skips that step entirely, which is why the difference shows up most dramatically exactly when it matters most: during a surge, when everyone in the area is loading the same pages in the same hour.

This is also where hosting stops being a line item and starts being a performance decision. A cheap shared host under load produces slow initial responses that no amount of image optimization compensates for, and the visitor experiences it as a page that does nothing for a second and a half before it even begins.

What speed is worth, honestly

Google’s page experience guidance is clear that Core Web Vitals form part of how it assesses pages, and equally clear that great page experience does not override having the most relevant, helpful content. Anyone selling you a rankings guarantee based on a speed score is overstating it.

The argument that holds up without any qualification is the commercial one. A homeowner who has just found a problem with their roof opens several results in quick succession and gives each a few seconds. The page that has finished loading and lets them tap call is the one that gets the inquiry. That is not a ranking factor, it is a conversion factor, and it is entirely within your control.

The same argument applies more sharply during a storm surge, when the whole area is searching at once, the phone signal is degraded, and everybody is comparing the same handful of roofers in the same ten minutes.

A note on the score people quote

The number most roofing companies have been handed by somebody is a single PageSpeed performance score, usually from a desktop test, usually of the home page. It is worth being clear about how little that describes.

It is one lab run, on one page, under simulated conditions, on the version of the site that existed the day it was run. It says nothing about the town pages that receive the search traffic, nothing about what a real visitor on a real phone experienced, and nothing about what happened after the next batch of job photos was uploaded.

That is not an argument for ignoring the score. It is a useful, comparable signal while you are changing things, and a low one is a reliable indicator that something is wrong. It is an argument against treating it as the goal, because optimizing for it specifically leads to strange decisions: stripping useful content to shave a tenth of a second, or deferring a script so aggressively that the page looks ready before it can respond to a tap, which improves the score and makes the experience worse.

The target to hold is simpler and harder to game: the three vitals in the good range, for real visitors, on mobile, on the pages that actually receive traffic, checked on a schedule.

How to check your own site properly

Do this on a phone, not on the office desktop with fibre.

Run the field data first. Look at what real visitors experienced over the last month, split by mobile, and look at the 75th percentile rather than the average. If there is not enough traffic for field data, that is itself useful to know, and lab data becomes the fallback.

Test the pages that matter, not the home page. The pages that receive search traffic are the service pages and the town pages. Those are frequently slower than the home page, because they carry galleries and were built later with less care.

Watch what happens in the first two seconds. Record the screen if you can. Does text appear before the image, or does the page sit blank waiting for a photograph. Does anything jump once it has appeared.

Tap something early. Tap the menu or the phone button as soon as text appears. If nothing happens for a beat, that is your INP problem in its natural habitat.

Check on a real connection. Throttled testing is useful, but standing in the street on a carrier signal tells you something a simulation cannot.

What to do with the result

If the site is slow, resist the urge to buy a caching plugin and declare it fixed. Caching helps with server response time and does nothing for a four megabyte photograph or a chat widget occupying the main thread.

The order that actually works is: fix the images, because that is usually most of the LCP problem; remove the third-party scripts nobody is using, because that is usually most of the INP problem; reserve space for anything that arrives late, because that is the CLS problem; and only then look at the platform itself. If the platform is the cause, which it often is, that is a rebuild conversation rather than an optimization one, and it is better to have it knowingly than to spend two years buying plugins to compensate for a plugin.

The last point is the one worth holding onto. Speed is not a launch-day score to be screenshotted and forgotten. It degrades every time somebody uploads a photo straight from a camera or adds a widget, which means it needs checking on a schedule rather than at the end of a project. A site that was fast at launch and has not been looked at since is very unlikely to still be fast, and nothing on it will tell you.