How does site speed actually feed into rankings?
Google does not hand you a ranking for being fast. It uses speed as one input among many, and the input has a name: page experience, measured by Core Web Vitals. Three numbers do most of the work. Largest Contentful Paint (LCP) is how long until the biggest thing on screen (usually your hero headline or photo) finishes painting. Interaction to Next Paint (INP) is how fast the page responds when someone taps the call button. Cumulative Layout Shift (CLS) is how much the page jumps around while it loads, which is what makes a thumb miss the tap target.
Speed is a tiebreaker more than a trophy. When two roofing sites both cover the same city, both have the reviews, both have the pages, the faster one gets the edge. Google has said page experience is a ranking factor but not the strongest one, relevance and links still lead. What that means for a contractor is blunt: a fast site will not out-rank a genuinely better-established competitor on speed alone, but a slow site hands away the ties, and in a competitive metro nearly every rank is a tie.
The second path is indirect and often larger. Google watches whether searchers get what they wanted. If your listing loads slow, people bounce back to the results and click the next contractor. That behavior tells Google your page did not satisfy the search, and over months that pulls you down. Speed protects the rankings you have, not just the ones you are chasing.
What do the speed numbers actually need to be?
Google publishes thresholds for the three Core Web Vitals. The scores are graded good, needs improvement, and poor. You want to land in the good band on mobile, because mobile is where contractor searches live. Here is the plain version.
| Metric | What it measures | Good (target) |
|---|---|---|
| LCP | Time until the main content paints | Under 2.5 seconds |
| INP | Response time when someone taps or clicks | Under 200 milliseconds |
| CLS | How much the layout jumps while loading | Under 0.1 |
Those are the passing lines. We build past them, not to them. The sites we hand-code aim for a usable page under 2 seconds and an LCP well inside the 2.5-second ceiling, because the ceiling is measured on real phones on real networks, not on the fast connection in your office. The gap between a lab score and a job-site score is exactly where most contractor sites fail.
One caution on tools. A green score in a lab test (like a one-off Lighthouse run) is not the same as field data. Google ranks on field data, the Core Web Vitals collected from actual Chrome users over 28 days. A site can score 95 in the lab and still fail in the field because the lab does not see the slow phone in the parking lot. When you check your speed, look at the field-data section, not just the lab number.
Why do most contractor websites load slow?
It is almost never one thing. Slow contractor sites are usually carrying weight they never needed. The usual suspects, in rough order of how often they wreck a site:
- Page builders and heavy themes. A drag-and-drop builder ships dozens of scripts and stylesheets to render a layout a hand-coded page does in a fraction of the bytes. The convenience in the editor becomes drag on every single visit.
- Plugin sprawl. A slider plugin, a form plugin, a chat widget, an analytics stack, a cookie banner, a review widget. Each one loads its own code. Twenty plugins is twenty tax bills on load time.
- Unoptimized photos. Contractors have great job-site photos, and they upload them straight off the phone at 4,000 pixels wide and four megabytes each. A gallery of those will bury a page. Images are the single most common LCP killer we find.
- Third-party embeds. Chat bubbles, booking widgets, map iframes, video players. Every embed calls out to someone else's server, and you inherit their speed, which you do not control.
- Cheap shared hosting. The $6-a-month plan puts your site on a crowded server. When the neighbor gets a traffic spike, your load time pays for it.
Notice what these have in common: they are all trade-offs someone made for convenience or price, and the visitor pays the bill. The contractor who bought a $500 template on the cheapest host did not choose to lose calls, but that is the invoice that came due.
How much does slow speed actually cost a contractor?
Speed is easy to wave off because it sounds technical. Put it in dollars and it stops being technical. The cost shows up in two places: rankings you never reach, and calls you already earned and then lost on the doorstep.
On the traffic side, Google's own data on bounce is stark. As page load goes from 1 second to 3 seconds, the chance a visitor bounces climbs sharply, and from 1 to 5 seconds it more than doubles. For a contractor that means half your hard-won organic clicks can evaporate before your phone number renders. You paid for those clicks in months of SEO work, and a slow site throws them away at the door.
Walk the math for one trade. Say your site pulls 400 organic visits a month and 5 percent turn into a call. That is 20 calls. If a faster site keeps even a third of the visitors a slow one loses, you are looking at a handful of extra calls a month, and one won roofing job or HVAC install can be worth thousands. Speed is not a vanity score. It is the difference between the pipeline you think you have and the one that actually reaches the phone.
The compounding cost is worse. Every visitor who bounces sends Google a small signal that your page did not deliver. Enough of those and your rankings slide, which means fewer visitors next month, which means the whole thing tightens. Slow is not a flat tax. It is interest.
How do you build a contractor site that loads under 2 seconds?
Fast is not a plugin you install at the end. It is a set of decisions made at the start, and most of them are about what you leave out. This is the lane we have worked since 2008, so here is the honest short list of what actually moves the needle.
- Hand-code static HTML. No page builder, no WordPress, no database call on every visit. A static page is already built and sitting on the server, so it ships the instant it is asked for. This is the single biggest lever, and it is a build decision you cannot bolt on later.
- Ship almost no JavaScript. Most contractor sites do not need a framework. A menu, a form, a click-to-call: that is a few kilobytes of vanilla script, not a megabyte of framework. Less code to download and run means faster response on a tap.
- Right-size and modern-format the images. Serve photos at the size they actually display, in modern formats, compressed, and load off-screen images only when the visitor scrolls to them. Reserve the space so nothing jumps.
- Cut the third-party weight. Every embed, widget, and tracker is a decision. Keep the ones that earn their load time, drop the rest.
- Host on fast infrastructure with a CDN. The page should be served from an edge close to the searcher, not one crowded box in a data center three states away.
A site built this way does not need a speed rescue later because it was never slow. That is the difference between fixing speed and never having a speed problem. The fixes on a bloated site are a game of whack-a-mole; the fast build is a foundation.
Can you make a slow WordPress site fast, or do you rebuild?
Fair question, because a rebuild sounds like a big swing. The honest answer is: it depends on how the slowness is baked in, and you should know both paths before you spend a dollar.
If the site is fundamentally sound and just carrying loose weight, tuning can help. Compressing images, adding caching, trimming plugins, and moving to better hosting can pull seconds off a page and often get it into passing range. That is real work with a real payoff, and for some contractors it is the right first move. Start there when the bones are good.
But there is a ceiling. A heavy theme and a page builder impose a floor on load time that no amount of caching gets you under, because the bloat is structural, it renders on every visit. We have seen sites where the honest recommendation is that you can spend $2,000 tuning a site to reach 3 seconds, or build a static one that starts under 2 and stays there. When the tuning bill approaches the rebuild bill, the rebuild wins, because you also get a site that is faster to update and does not rot as plugins fall out of date.
Here is the test we use. Run the field data. If the site is close to passing and the fixes are obvious, tune it. If it fails badly, if the builder is the problem, or if you were going to redesign anyway, rebuild it right once. The worst outcome is spending real money making a slow site slightly less slow, then rebuilding a year later anyway. A speed audit tells you which path is yours before you commit.