Some HVAC contractor sites take 9 seconds to render on mobile: five fixes that move the number

I run the dataset behind Full Stack HVAC's site-quality work. We have run over 1.1 million Lighthouse audits on U.S. HVAC contractor sites, and about 18% of them load too slowly on mobile, with Largest Contentful Paint over 2.5 seconds.¹ Google publishes 2.5 seconds as the boundary between "good" and "needs improvement", and 4.0 seconds as the start of "poor".² The median site is fast, it paints in under a second on a phone, so this is not a problem every contractor has. But the sites that are slow are not slow by a little: the 11% of mobile audits in the "poor" tier average about 9.5 seconds, more than double the poor threshold, on the device the customer is actually using.

The problem is the tail, not the median

The reason most contractors do not worry about mobile speed is that they look at their own site on the device they own, a desktop or a recent-vintage iPhone on the office Wi-Fi. On a fast device and connection, most of these sites are fine. At the median, a phone actually paints them a touch faster than a desktop does (a mobile mean near 1.9 seconds against 2.2 on desktop).

The damage is in the tail. The slowest mobile experiences are far worse than the slowest desktop ones, and the tail is where the lost calls live. Here is the mobile Largest Contentful Paint distribution across the audit set:

So the "9-second site" is real, but it is the poor tier, not the typical site. About 1 in 9 mobile audits lands there, and that band averages 9.5 seconds. The tail is also heavier on mobile than on desktop: at the 90th percentile, mobile LCP is 4.4 seconds against 3.8 on desktop, and mobile first paint is 2.8 seconds against 1.6. The slowest desktop experience the operator might glimpse is not as bad as the slowest mobile one the customer hits. The customer never sees the desktop score.

What 9 seconds costs on the call you actually want

Walk through the search the dataset is built around. A homeowner's heat pump fails on a February evening. They unlock the phone and search for emergency HVAC repair plus the city. Google shows the map pack and three organic results. They tap the first contractor.

If that site is in the slow tier and takes 9 seconds to render, the homeowner has already tapped back and chosen the next contractor before the hero loads. Google's own Think with Google research from 2017, replicated in several follow-ups, put the three-second mobile-abandonment rate in the 50 to 55% range across consumer-service queries.³ The number has been measured and re-measured; the operational lesson has held. The competitor's site that loaded in 2 seconds, showed a phone number, and dialled on a tap is now in the conversation. The slower site never was.

Quality of work cannot be evaluated from a homepage that has not yet rendered.

Where the seconds go on a typical HVAC contractor site

The Lighthouse data flags the same handful of root causes across most of the slow sites in the dataset:

• Unoptimized hero images. Hero shots stored at 4,000 px wide, served as PNG or unoptimized JPEG, no responsive variants. A single oversize hero routinely adds 3 to 5 seconds on mobile LCP.
• Heavy theme bundles. Pre-built WordPress or Wix themes that ship 30 to 50 JavaScript files, most of which the contractor site does not actually use. Each file is a parse and execute cost on the phone.
• Third-party widgets. Live-chat, analytics, social-proof badges, social-media embeds. Each adds 0.5 to 2 seconds of script load and execution. Five widgets is a slow site by itself.
• No CDN. Images served from a shared-host server in a different region. A simple CDN (Cloudflare, Bunny, BunnyCDN, Fastly) moves the same images to an edge node and removes most of the network latency.
• Render-blocking CSS and JavaScript. Stylesheets and scripts loaded synchronously in the head, blocking first paint until the entire bundle has arrived. The fix is to mark non-critical assets as deferred or async.

The three elements that have to load in under 2 seconds

For an emergency-search homepage, the contractor only needs three elements to render before the homeowner can act on them. Everything else can stream in afterwards.

1. The phone number in the header, tappable. Visible without scrolling, large enough to tap accurately on a phone screen (Google's accessibility guidance is a 48 px tap target minimum).
2. The click-to-call button. Not a form. A button that fires a tel: link on tap, with the same phone number the GBP listing carries.
3. The recency signal on reviews. Star rating, review count, and the date of the most recent review. The date is the part the customer reads as "this contractor is still in business and still doing work this month".

If those three render fast, the rest of the page can take its time. The homeowner is already on the call.

Five fixes, in priority order

1. Compress and resize the hero images. Convert PNG and JPEG to WebP or AVIF. Cap the resolution at 1,200 px wide on desktop and 800 px on mobile. Free tools that do this without re-encoding artifacts: Squoosh (Google), TinyPNG, and the built-in WordPress image-optimizer plugins (Smush, Imagify). On most contractor sites in the dataset, this single change moves mobile LCP by 3 to 5 seconds.
2. Defer non-critical JavaScript. Chat widgets, analytics, social-proof badges, and social-media embeds load after the page is visible, not before. In WordPress, the WP Rocket or Perfmatters plugins expose the toggle; in custom builds, mark the script tags defer or async.
3. Turn on browser caching and a CDN. Most hosting providers (SiteGround, Kinsta, WP Engine, Cloudflare Pages) ship this as a toggle. Cache headers stop returning visitors from re-downloading the same hero on every visit; the CDN moves static assets to a node near the homeowner.
4. Self-host the fonts. Google Fonts adds two DNS lookups and a render-blocking CSS file in the default configuration. Download the WOFF2 files, host them on the same domain, and inline the @font-face declaration. Saves 200 to 600 ms on most contractor sites.
5. Test on a real phone, on cellular, away from the office. Pull a five-year-old Android out of a drawer if you have one. Open the site on LTE, not Wi-Fi. Time the hero. If it is over 4.0 seconds, the site is in Google's "poor" tier on the device the customer is using.

The Google PageSpeed Insights page at pagespeed.web.dev is the canonical first-pass tool; it pulls the same Lighthouse engine the Full Stack HVAC dataset uses. Run the site through it before and after each fix and watch the LCP number move.

What to do this week

1. Run the homepage through pagespeed.web.dev. Record the mobile LCP. Anything over 4.0 is "poor".²
2. Compress the hero. WebP or AVIF, capped at 1,200 px wide. Re-run the audit and confirm the LCP moved.
3. Defer the chat widget and the analytics script. Re-run the audit.
4. Switch on the CDN if the host offers one. Cloudflare's free tier covers most contractor sites.
5. Open the site on a real phone, on cellular, from a parking lot. Watch the hero render. That is what the customer is seeing.

The Lighthouse dataset says most contractor sites are fine on a phone, but a stubborn slow tier is reachable yet not usable in the seconds that decide an emergency call. Each of the five fixes above is reachable without a rebuild, and the order is the order they move the number.

For the broader question of how many contractors have a website in the first place, see the no-website analysis. For the dispatch-software-bundled site option, see the dispatch-software comparison.