HVAC Website Speed: Core Web Vitals Without the Jargon

The cleanest causal evidence on speed and leads is a controlled A/B test, and it is not from HVAC. Vodafone ran two landing pages that were visually and functionally identical, differing only in performance work, and found that a 31% improvement in LCP produced 8% more sales, a 15% uplift in the lead-to-visit rate and an 11% uplift in the cart-to-visit rate. Vodafone's Davide Grossi, credited on the case study as Head of Digital Marketing, Business, put it this way: "Thanks to the collaboration with Google and the introduction of LCP as the main KPI for page performance, it was possible to significantly improve the customer experience of our e-commerce." Telecoms e-commerce is not a furnace call at 9pm — but the lead-to-visit figure is the closest published proxy for what an HVAC site is trying to do.

The HVAC speed statistics circulating right now do not survive a check

Two numbers dominate this topic in contractor marketing content, and both fail when you follow the link. The page ranked seventh for "website speed hvac" states "Studies show that 47% of users leave a site if it takes more than 3 seconds to load" and links it to a web-design agency's statistics roundup. That roundup does not contain the claim. What it says is "47% of Users expect a maximum of 2 seconds loading time" — a different number about expectation, at a different threshold — passed onward to another blog rather than to a study. A stated expectation of two seconds became a measured abandonment rate at three seconds somewhere in the retelling.

The page ranked first states "53% of mobile visitors abandon a site that takes longer than three seconds to load" and attributes it to "Google's research" with no link to follow. Neither page is dishonest; both repeat what the niche repeats. The consequence is that contractors are told to hit a threshold nobody in the chain measured.

The defensible version: Google publishes a target — 2.5 seconds for LCP at the 75th percentile — and states that Core Web Vitals feed its ranking systems. One controlled A/B test outside HVAC links a 31% LCP improvement to a 15% lead-rate uplift. Nobody has published a controlled study of HVAC website speed against booked jobs, so anyone quoting the exact revenue a second is worth to your shop is guessing — and no one can guarantee a #1 ranking on Google on the back of it.

Three details change how you read any tool's output. First, the thresholds apply at the 75th percentile of page loads, segmented across mobile and desktop — so three quarters of real visits must clear the bar, and your fast desktop test proves nothing about the phone in the driveway. Second, First Input Delay is retired; any HVAC marketing page still listing FID as a Core Web Vital is running on stale information. Third, and most useful when a vendor waves a screenshot at you: Google's own lab-tools table gives Lighthouse a check for LCP and CLS but blocks its INP cell with "use TBT instead". A green Lighthouse performance score is a lab estimate of two-and-a-bit metrics, not a Core Web Vitals pass.

CLS is a unitless score, not a duration — "CLS of 0.1 seconds" is a tell that the report's author is misreading their dashboard.

Method, stated so you can discount it properly. Every number in this section is our own measurement taken through DataForSEO on 17 August 2026 — tool data, not a Google-reported metric, and not a figure either company publishes. The runs are desktop (for_mobile left at its default) on a simulated 10 Mbps connection at 40 ms round-trip time with no CPU slowdown — conditions kinder than a real homeowner's phone on cellular data, so the real-world numbers are worse, not better. This is lab data, not the field data Google actually assesses, and ten pages is a convenience sample, not a survey of the US contractor market. Under simulated throttling, server response is observed while LCP is modelled, so the two can disagree — the Goettl row below records a 2,295 ms server response alongside a 1.24-second LCP for exactly that reason.

Seven of the ten missed Google's 2.5-second LCP target and three were past the 4.0-second "poor" line. Median LCP was 3.42 seconds; median page weight 3.92 MB, against a median desktop page weight of 2,652 KB across the whole web in the Web Almanac's October 2024 dataset. All ten came out of the organic results we pulled, slow ones included — but we recorded no positions, so the sample shows that pages this slow rank at all, not how high.

The measurements rank the five causes in this order:

1. Weight, and specifically the hero image. Seven of ten pages exceeded 3 MB and three exceeded 5 MB, topping out at 8.04 MB on one service page. Images are the largest single byte category web-wide — the median desktop page requests 1,054 KB of images against 613 KB of JavaScript — and on a contractor site the LCP element is almost always the full-width photo of a truck or a technician. Google budgets roughly 40% of LCP to downloading that resource.
2. Third-party scripts. The median page loaded resources from 15.5 outside companies — the ten counts run 4, 4, 5, 11, 12, 19, 21, 27, 27 and 31. Chat widgets, review carousels, tag managers and remarketing pixels each arrive as somebody else's JavaScript on your critical path. We logged the count per page, not the identity of each company, so treat this as a measure of how many outside parties the page depends on rather than of what they do.
3. Server response time. Three of ten took over 800 ms to return the first byte, one of them 2,295 ms, before a single image was requested. Google budgets about 40% of LCP to Time to First Byte, so a two-second server response has spent the entire allowance twice over. That is a hosting and caching problem, not a design problem.
4. JavaScript that blocks the tap. One page paints fast — 1.69-second LCP — then locks up: 2,972.9 ms of Total Blocking Time and 4,382.8 ms of script execution. The hero looks instant and the call button ignores the first press. A screenshot of a fast paint hides this failure completely.
5. Stacking — and not the platform everybody blames. One bad reading on its own did not push a page past 4 seconds here: anyhourservices.com carried 6.75 MB and 2,972.9 ms of blocking time and still painted in 1.69 s, and Goettl's 2,295 ms server response still painted in 1.24 s. The three pages that did cross 4 seconds carried 21, 27 and 27 third-party companies — three of the four highest counts in the sample — and two of them stacked a second problem on top: abacusplumbing.net is the heaviest page here at 8.04 MB, collinscomfort.com returns its first byte in 921 ms. What did not separate them was the platform each page runs on. We re-fetched all ten pages on 18 August 2026 and searched the delivered HTML for CMS and page-builder markers: the three slowest carried none, and the one Elementor build we could reach (callhero.com, 2,715 references to Elementor in its HTML) came fifth of ten at 3.38 s. Four pages refused that re-fetch with a 403 or a bot-challenge page, and only two of the six we could read named a platform at all — so eight of the ten are a blank to us, which is its own argument against blaming one.

What was not the problem: layout shift. Eight of the nine pages reporting CLS were already inside Google's 0.1 "good" band, several at effectively zero. One page sat at 0.778, triple the "poor" threshold — the same page carrying 31 third-party companies. Generic advice tells every contractor to fix their layout shift; eight of these ten would have been fixing something that already passed.

Six pages we could not measure, reported because omitting them would flatter the result: two redirected our tester to a captcha challenge page, two returned a document request error, and two returned a stripped ~0.70 MB response with nothing beyond their CDN's bot-protection layer. If measurement tools cannot reach your site, that is worth knowing on its own.

1. PageSpeed Insights, and read the top half only. Enter your busiest service page at pagespeed.web.dev. The upper block is field data — "anonymized performance data from users in the real-world on a variety of devices and network conditions" over the previous 28-day collection period. That is your actual Core Web Vitals assessment. The score out of 100 below it comes from a Lighthouse lab run and is a diagnostic, not a verdict.
2. Switch to the Mobile tab and stay there. Desktop numbers flatter every contractor site in this niche. Homeowners searching "AC not cooling" are on phones.
3. Open Search Console's Core Web Vitals report. Google names it among its field data sources alongside the Chrome User Experience Report. It groups URLs by template, which tells you whether the problem is one page or every service page your builder generates from the same layout.

Three traps sit in that output. A green Lighthouse score is not a pass — Lighthouse reports no INP, and a pass needs all three metrics at the 75th percentile in field data. Field data lags 28 days, so last week's fix will not show yet; confirm in the lab numbers and wait. And "no data available" is not a pass — it usually means too little Chrome traffic to report, which is its own diagnosis.

If a vendor sends a single screenshot of a 98 score as proof of work, ask which URL, which form factor, and whether the field data agrees. The third answer is the one that matters.

Items 1 through 3 are the ones a non-technical owner can commission, verify and pay for without a rebuild, and we take that remediation work as its own engagement, quoted per shop, with no build attached. Item 6 is the honest answer when a site carries eight megabytes and 27 third-party companies, as one page in our sample does, and every earlier fix returns tenths of a second — which is why it belongs in the performance floor we hold every HVAC build to rather than bolted on afterwards.

Set a baseline before you touch anything: screenshot today's PageSpeed Insights field data for your three highest-traffic service pages, then re-check after each fix. Without it you cannot tell a real improvement from a good day on Google's servers.

• Whether the page asks for the call. A 0.7-second LCP over a buried phone number books nothing — what the page has to do once it loads is a separate, better-evidenced list.
• Whether machines can read it. Four of the sixteen contractor pages we tried served our tester a bot-protection challenge instead of the page, and two more failed the document request outright. Whether the crawlers behind AI answers can reach your pages at all is a five-minute check with a very different fix.
• Whether machines can interpret it. Once a page loads fast, the structured data worth adding to an HVAC site tells engines what you do and where you do it.

For the on-page fundamentals that sit alongside speed — titles, indexability, viewport, canonical tags — a ten-check pass over your on-page basics covers them. It does not measure Core Web Vitals; use PageSpeed Insights for that.

We have no before-and-after of our own to show yet, so here is the live measurement we do hold, including the half that argues against us. On the one HVAC engagement we can evidence with Search Console data — a Winston-Salem HVAC and refrigeration contractor — organic clicks are up 234.4% and top-10 ranking keywords up 426.2% since engagement start, measured in Google Search Console to 14 August 2026. That growth has plateaued rather than continued: it peaked around 24 July 2026 at 2,486 monthly clicks and stood at 1,886 on 14 August. The constraints we can currently measure on that account are the ones this page is about — an LCP of 4,260ms against Google's 2,500ms "good" threshold, and 411 unindexed URLs against 268 indexed. A site can earn the ranking and still lose the load, and the second number is where that account's next month of work goes.