Speed Up a Slow Contractor Website: 6 Fixes

If your contractor website is slow, fix these three things in this order: the hero image at the top of the page, the page builder rendering the layout, and the third-party widgets you bolted on afterwards. On most home service sites, those three account for the majority of the delay, and all three are fixable in an afternoon without touching your platform.

But before you touch any of it, ignore the score. The number in the coloured circle on PageSpeed Insights is a lab simulation, not the number Google evaluates, and it is the single most common reason contractors spend a weekend optimizing something that was never the bottleneck.

Stop chasing the PageSpeed score

The score is a diagnostic. It is not what Google ranks on.

PageSpeed Insights shows two different things stacked on the same page. The top section, when it appears, is field data from the Chrome User Experience Report: measurements from real Chrome users who actually visited your site, taken at the 75th percentile over a rolling 28-day window. That is what Google's page experience systems assess. The bottom section is Lighthouse, a single simulated load on Google's hardware, throttled to roughly 1.6 Mbps with a 150ms round trip. That is the coloured circle everybody screenshots. The two disagree constantly, and they are supposed to.

Here is the part almost nobody tells contractors: your site probably has no field data at all. Google requires a minimum volume of real Chrome visits before it will report Core Web Vitals for a URL, and it has never published the number. Sites under that bar get no URL-level data. Google falls back to origin-level data, which averages every page on your domain into one figure, and origins with very little traffic get nothing. A three-truck plumbing company doing four hundred visits a month is nowhere near the threshold.

So if you are optimizing to move a ranking, and Google has no field measurement of your site to move, you are optimizing a number that exists only inside a simulator.

The three numbers that actually count

Core Web Vitals is three metrics, each with a threshold you must clear at the 75th percentile of real visits. All three have to pass at once. One metric in the middle band fails the whole assessment.

INP replaced First Input Delay on 12 March 2024, which matters when you read older advice. FID only measured the very first tap. INP measures responsiveness across every interaction in a session, so it is a considerably harder bar and any pass-rate data from before that date is measuring something easier.

As of the May 2026 CrUX release, 55.9% of the roughly 18.4 million tracked origins passed all three, down 0.8 points from April. Split by device, the 2025 Web Almanac put mobile origins at 48% versus 56% on desktop. And within the three metrics, one is doing almost all the damage: on mobile, about 62% of pages achieve a good LCP, against roughly 77% for INP and 81% for CLS.

Loading is the bottleneck. Not interactivity, not layout shift. If your site is failing, LCP is the likely culprit and the first place to look. The Web Almanac also found home pages pass at 45% on mobile while secondary pages pass at 56%, because home pages carry the heaviest hero media. Your homepage is the hardest page on your site to make fast, and it is the one you keep testing.

What speed actually buys you

Not rankings. At least, not much.

Google Search Advocate John Mueller has been consistent about the size of this signal: "It is a ranking factor, and it's more than a tie-breaker, but it also doesn't replace relevance." Google's own page experience documentation goes further, stating that Search "always seeks to show the most relevant content, even if the page experience is sub-par." There is no single page experience signal, and no published weight.

Where speed pays reliably is in two places nobody puts in the headline.

One: paid clicks get cheaper. Google Ads uses landing page experience as an input to Quality Score, and load speed feeds that assessment. Agency-reported figures put the gap between "below average" and "above average" at a 16% to 30% swing in cost per click on the same keyword and bid. Those are vendor numbers, not Google's, so treat the magnitude as directional. The mechanism is not in dispute: a slow landing page costs more per click than a fast one for identical targeting. If you are spending $3,000 a month on search ads for emergency plumbing, that is the highest-return speed argument in this article, and it has nothing to do with organic rank.

Two: people stop leaving. This is the one contractors feel. A window cleaner's site rebuild posted to r/juststart in 2026, which drew 621 upvotes and 213 comments, is the clearest public example. The original site took about six seconds to load, had a broken SSL certificate and still had %%h1%% sitting live on the homepage where the template placeholder was never replaced. After the rebuild it loaded in under a second. Three days later the owner texted the developer: "What have you done to my site the phone won't stop ringing."

Read that case honestly, though, because it is also a lesson in attribution. A commenter in the same thread went and checked. Searching the target term, they found the site "about 3/4s of the way down the page after 5 sponsored results," and could not find the business named in any AI answer. The rebuild had also added 28 area pages, real photos and schema markup alongside the speed fix. The phone rang. Speed was one of several reasons.

The developer's summary of why any of it worked is the most useful line in the thread: "The bar for local business websites is on the floor. You're not competing against good sites. You're competing against nothing."

Diagnose before you fix: three tests, fifteen minutes

Skip this and you will spend a weekend shaving 200ms off something that was never costing you a job.

Test 1: measure the money path, not the homepage. Your customers arrive from Google Business Profile and from search, and the thing they need is a phone number or a form. Run PageSpeed Insights on the page they actually land on and the page where they actually convert. If your booking form lives on /contact, that URL is your money path. A slow homepage that nobody converts on matters less than a slow quote form.

Test 2: use a real phone on cellular data. Turn wifi off. Clear the browser. Load your site. Count out loud. This takes ninety seconds and it is the only test that reflects what a homeowner experiences. One local service operator described the failure mode exactly on r/smallbusiness: an agency ships a heavy site with video backgrounds and fade-in animations, and "on a spotty 4G mobile signal at a job site, it takes 6 seconds to load." A designer in the same thread put the customer's side of it plainly: they "shouldn't have to sit through a 6-second animation to find a phone number."

Test 3: check field data separately from lab data. In PageSpeed Insights, look for whether the field section appears at all. If it says there is not enough data for this URL, stop treating the Lighthouse score as a ranking input and use it only as a before-and-after diagnostic on your own changes.

Write down three numbers before you start: load time on a real phone, LCP from the field section if it exists, and your lead count for the last thirty days. Speed work that does not move the third number was not worth doing.

The six fixes, in the order that pays

Ranked by how much time they typically recover on a contractor site versus how long they take.

1. The hero image

The 2025 Web Almanac put the median mobile home page at 2,362 KB. A single unoptimized photo straight off a phone can be double that on its own.

Your hero image is almost certainly your LCP element, which makes it the one thing standing between you and the metric that fails most sites. Resize it to the width it actually displays at, around 1920px for a full-bleed desktop hero and far less on mobile. Export it as WebP. Then serve different sizes with srcset so a phone downloads the phone version and not the desktop one.

Do the same to every before-and-after gallery. Twenty phone photos at 4MB each is 80MB, and no amount of caching saves you from the first visit.

2. The page builder

Elementor, Divi and WPBakery generate large CSS and JavaScript bundles that load on every page whether you used those features or not, and they add render-blocking resources even on a page with three elements on it. Vendor testing suggests Elementor alone ships over 20MB of unzipped code into an installation, and that builder-heavy pages routinely exceed 500ms INP on mobile. Treat the exact figures as vendor-reported. The pattern is not controversial.

If you cannot migrate off the builder, turn on its own performance settings: Elementor's optimized DOM output and optimized asset loading, or Divi's equivalents. Then delete the widgets, animations and sliders you are not using. Every unused module is still shipping its code.

3. Third-party widgets

Review carousels, chat bubbles, booking embeds, tracking pixels, a Facebook feed nobody looks at. Each loads its own JavaScript from someone else's server, and most load without defer, meaning the browser stops rendering your page to fetch and run somebody else's code. Three of them stacked together is the usual cause of a page that looks loaded but does not respond when you tap the menu, because the main thread is busy parsing scripts. That is exactly what INP measures.

Audit them by asking one question each: has this widget produced a lead in the last ninety days? If you cannot answer, it goes.

4. The map embed

A live Google Maps iframe on a contact page pulls an entire interactive mapping application into your site. Replace it with a static map image that links out to Maps. Your customer wants to know roughly where you are and then get directions in their own app. They were never going to pan around inside your website.

5. Caching and a CDN

Caching stops your server rebuilding the same page from scratch for every visitor. A CDN serves your files from a location near the visitor rather than from wherever your host's data centre happens to be. Both are close to free at contractor traffic volumes, and together they attack server response time, which sits underneath LCP. This is the easy one. It is also the one that does nothing if your hero image is 4MB. Order matters.

6. Reserved space

CLS is the metric most sites already pass, and the cheapest to fix. Give every image explicit width and height attributes, reserve a box for anything injected late, and stop the popup that shoves the whole page down after two seconds.

A commenter on r/smallbusiness described that last one from the customer's side: the mailing list popup "takes up the entire screen and you literally can't get rid of it so I have no choice but to back out." That is not a Core Web Vitals problem. That is a lost job.

Your platform already placed a bet

Before you write a line of code, your platform has set your odds. These are field pass rates from November 2025 HTTP Archive data, not lab tests.

Two conclusions contractors usually draw from this table are wrong.

The first is that hosted builders are the slow ones. Wix and Squarespace both comfortably beat WordPress in the field. If you are on Wix and someone is quoting you for a speed rebuild onto WordPress, the population data says you are about to move in the wrong direction.

The second is that WordPress is broken. Look at the INP column: WordPress passes at 85.89%, essentially level with Wix at 86.82%. WordPress sites are responsive. What they fail is loading, which is images, theme weight and server response time, and every one of those is something you control. The platform sets the floor. Your build decides the outcome.

Three myths worth killing

"Responsive design already makes it small and fast on mobile." This came up almost verbatim in an r/smallbusiness thread, and it is the most expensive misunderstanding on this list. Responsive CSS changes how the layout is arranged at different screen widths. It does not change the size of the files being downloaded. Without srcset and sizes, a phone downloads the same 4MB desktop hero and scales it down after paying for every byte. Resizing on screen is not resizing on the wire.

"We got the score to 100, so we're done." You got the lab number to 100 on a simulated connection. Re-check the field section four weeks later, because CrUX runs on a 28-day rolling window and will not reflect your fix before then. Concluding a fix failed after three days is a mistake people make constantly.

"The site is slow, so we need a rebuild." Sometimes. But image compression and script removal will tell you within a week how much of the problem was weight, and they cost an afternoon instead of five figures. If you are being sold a rebuild, ask what the quote does that a compression pass does not.

Rebuild or optimize

Optimize when the site is structurally fine and merely heavy: the pages exist, the phone number is findable, the forms work, it is just slow.

Rebuild when speed is a symptom rather than the disease. The tell is that the site also fails the things speed cannot fix. No page for each area you serve. No clear way to become a lead other than calling during business hours. No tracking on the calls you already get, which means you cannot tell whether any of this worked. If three of those are true, you are not buying speed, you are buying a website, and that is a different budget conversation. We covered what a contractor should actually spend on marketing separately.

And if traffic is arriving but the phone still is not ringing after you fix the speed, the problem was never load time. That diagnosis has its own post, because in most cases the calls are already happening and nobody is counting them.

The weekend checklist

1. Load the site on your phone with wifi off. Time it. Write the number down.
2. Run PageSpeed Insights on your landing page and your contact page. Note whether field data appears at all.
3. Resize and compress every image above the fold. WebP, correct display width, srcset in place.
4. Compress the gallery photos. All of them.
5. List every third-party script on the site. Delete any that has not produced a lead in ninety days.
6. Replace the live map iframe with a static image.
7. Turn on caching. Put the site behind a CDN.
8. Give every image explicit dimensions. Kill any popup that fires in the first three seconds.
9. Re-test on the phone. Compare against step 1.
10. Diarise a check of the field data for four weeks out.

The honest version

Most contractor sites are slow for one reason: somebody uploaded a photo straight off a phone. Everything else in this article is a rounding error next to that, and it is why the fix order in this article starts where it does.

The second thing worth internalising is that speed is not a ranking strategy. It is a conversion and cost strategy. It makes the visitors you already paid for more likely to call you, and it makes the clicks you buy cheaper. If you want to rank, that work is reviews, service area pages and relevance, and no amount of milliseconds substitutes for it.

The third is the encouraging one, and it comes from the developer who rebuilt that window cleaner's site: the bar is on the floor. Broken certificates, template placeholders left live for years, six-second homepages with a video background. A customer on r/smallbusiness described what they actually want from a local service site: "the phone number, hours, and service area fast." That is the whole brief. Most of your competitors are not delivering it, which means an afternoon of image compression genuinely can move you ahead of them. Not because Google rewarded you, but because the homeowner in the driveway did not give up and go back to the results page.

Start with the lead generation fundamentals if you are building from zero. Otherwise, start with the hero image.