Slow Homepage Costs Leads Before Forms Start

Opening answer

A slow homepage costs you leads because visitors leave before they see the offer, start a form, or tap Call. Google's Core Web Vitals treat that delay as a user-experience failure, not a developer vanity score: Largest Contentful Paint (LCP) should happen within 2.5 seconds, Interaction to Next Paint (INP) within 200 milliseconds, and Cumulative Layout Shift (CLS) at 0.1 or less, each measured at the 75th percentile of real visits.[1] When those numbers slip, bounce rises and form starts fall. Search ranking is a side effect. The money sits in the first paint, the first click, and the first field someone almost filled out.

The first paint is the first impression of your business

Owners talk about "the site being a bit slow." What that actually means on a phone is simpler. Someone searched, tapped your result, and waited. If the hero, headline, or phone number did not appear quickly, they went back. That is not a technical complaint. It is a missed quote request.

The vintage numbers still get quoted because they were blunt. In February 2017, Think with Google reported that 53% of mobile site visitors leave a page that takes longer than three seconds to load.[2] The same Google/SOASTA research found that as load time went from one second to three seconds, the probability of bounce rose 32%. From one second to five seconds, bounce probability rose 90%.[2] Those figures are nine years old. Devices got faster. Pages also got heavier. The behavior did not reverse.

A Google-commissioned study published in 2020 (Milliseconds Make Millions, field work at the end of 2019 across 37 brand sites and more than 30 million sessions) put a price on small gains. A 0.1 second improvement across four speed metrics lifted funnel progression. On lead-generation sites, users who reached the form-submission page rose 21.6%, and page views rose 7%.[3] Shave a tenth of a second and more people start the form. Waste a second and they never do.

Later Core Web Vitals case studies made the same point with LCP instead of generic "load time." In a 2021 A/B test, Vodafone improved LCP by 31% on a landing page and recorded 8% more sales plus a 15% lift in lead-to-visit rate. The two variants were visually identical. The only change was performance.[4] In 2022, Farfetch reported that once LCP moved past Google's 2.5 second "good" line, conversion rate fell about 1.3% for every extra 100 milliseconds of LCP. Layout shift hurt too: exit rate dropped 3.1% for each 0.01 improvement in CLS.[5]

If you sell services, those percentages are phone calls and quote forms. A slow homepage does not announce itself as a marketing failure. It just quietly withholds the next step.

Stop grading the lab. Grade the visit.

Lighthouse scores are useful. They are not the thing Google Search uses, and they are not the thing your visitor feels. PageSpeed Insights reports two different pictures. Lab data is a simulated load on a mid-tier phone. Field data comes from the Chrome User Experience Report (CrUX): real Chrome users over a trailing 28-day window.[6] CrUX is also the dataset Google Search draws on for page-experience ranking.[7]

The field number that matters is the 75th percentile, split by mobile and desktop. That is the point Google chose so a site has to work for people on slower phones and weaker networks, not just for the office fiber connection.[1][6] A page "passes" Core Web Vitals only if LCP, INP, and CLS are all in the good bucket at that 75th percentile.[1][6]

Google's ranking systems do use Core Web Vitals. Google is also clear that a green report does not guarantee top rankings, and that chasing a perfect lab score just for SEO is often a poor use of time.[8] We agree. Treat the score as a conversion instrument. If mobile LCP is 4.2 seconds, the ranking debate is a distraction. The form never started.

INP replaced First Input Delay as the responsiveness Core Web Vital on March 12, 2024. FID only measured the delay before the first event handler ran. INP watches clicks, taps, and keypresses across the whole visit and reports a value that nearly all interactions beat.[9] Chrome usage data shows that 90% of a user's time on a page is spent after it loads.[9] That is why a homepage can "look loaded" and still lose the lead: the menu, the click-to-call, or the first form field does not paint a response in time.

Good INP is 200 milliseconds or less. Needs improvement is 200 to 500 milliseconds. Poor is over 500.[1][9] If someone taps Request a Quote and nothing visibly happens for half a second, they do not think "JavaScript is busy." They think the site is broken, and they tap again or leave.

Homepages fail more often than the rest of the site

If you only tested an inner page, you have not tested the page that has to earn the visit. HTTP Archive's 2024 Web Almanac (CrUX plus lab crawls, published November 2024) found that home pages are the weak link.

On mobile, 38% of home pages had good Core Web Vitals, against 51% of secondary pages. On desktop, 45% of home pages passed, against 61% of secondary pages.[10] LCP tells the same story. 53% of mobile home pages had good LCP, versus 72% of mobile secondary pages. Desktop home pages sat at 63% good LCP, versus 82% for secondary pages.[10]

That gap is not mysterious. Homepages carry the hero video, the carousel, the chat widget, the tag manager, the review badge, and three font families. Inner pages often inherit cached CSS and skip the heaviest media. Visitors, though, land on the homepage first. Caching does not help the cold load that decides whether they stay.

INP does not get the same homepage-versus-inner-page gift. In 2024, 73% of mobile home pages had good INP, almost identical to secondary pages. Desktop was already at 96%.[10] Interactivity is a main-thread problem. It follows the JavaScript you ship, not the cache you hoped would save you.

The loading numbers should bother anyone who paid for a heavy homepage. Only 59% of mobile origins had good LCP overall (72% on desktop). 35% of mobile pages had an LCP image that was not discoverable in the initial HTML. 16% of mobile pages with an image LCP were lazy-loading that image.[10] Chrome's 2024 guidance put a clock on that mistake: among origins with poor LCP, the LCP image was delayed on the client by 1,290 milliseconds at the 75th percentile, more than half of the 2.5 second budget. Most of those origins spent less than 10% of LCP time actually downloading the image. The time was wasted waiting to start.[11]

What each vital feels like on a homepage

LCP is "when does the main thing appear?" On most homepages that thing is the hero image, a large headline, or a video poster. 73% of mobile pages in the 2024 Almanac used an image as the LCP element.[10][11] If that image is a 2 MB JPEG, a CSS background, a slider that JavaScript has to initialize, or an image tagged `loading="lazy"`, the visitor stares at a blank or a spinner while your competitor's page is already readable.

INP is "when I tap, does anything happen?" A homepage is a cluster of interactions: mobile nav, phone link, form field, chat launcher, cookie banner, "Get a quote." INP measures from the tap to the next paint, including input delay, handler time, and presentation delay.[9] Third-party scripts are a frequent cause. The 2024 Almanac noted that presentation delay is the main contributor to poor INP, often from behavior-tracking scripts, consent providers, and related third parties.[10] A tag that never shows up in your design file can still freeze the first tap on the form.

CLS is "did the page jump as I reached for it?" Good CLS is 0.1 or less. Poor is above 0.25.[1] The classic homepage version is an unsized hero, a late webfont, or a banner that shoves the Call button down at the exact moment a thumb is on it. In 2024, 66% of mobile pages still failed to set explicit dimensions on at least one image.[10] That is not a polish issue. It is accidental taps and rage-backs.

None of these require you to become a performance engineer. They require you to stop treating a 4 second hero as "fine, it loads on my laptop."

The four places delay actually lives

You do not need a plugin-tuning tutorial. You need to know where homepage time goes so you can ask the right questions.

1. The hero. If the largest visible element is an image, it should be a real `<img>` in the HTML, sized with width and height, compressed, and loaded with high priority. It should not wait for a slider library, a CSS background, or a `data-src` swap. Chrome's top recommendation for LCP is exactly this: make the LCP resource discoverable in the HTML and prioritize it. Only 15% of eligible mobile pages in 2024 were using `fetchpriority` on that image.[11] Do not lazy-load the hero. Lazy-loading is for content below the fold.

2. Third-party tags. Analytics, ads, chat, heatmaps, A/B tools, and consent banners compete for the main thread. They rarely appear in the mockup, and they often load on every page including the homepage. Audit the tag manager. If a tag does not earn a lead, it does not belong on the first paint. Load non-essential tags after the hero is up, or keep them off the landing experience entirely.

3. Fonts. Custom type that blocks rendering delays LCP when text is the largest element, and it causes CLS when the webfont swaps in and reflows the headline or the form. Limit families and weights. Use a `font-display` strategy that shows fallback text quickly. Preload only the one or two files the first screen actually needs.

4. JavaScript. Each kilobyte has to download, parse, and run on the visitor's phone. Long tasks (work over 50 milliseconds) block the next paint and show up as bad INP.[9][11] Carousels, animation libraries, and engagement widgets are frequent offenders. If the homepage can explain the business and start a form without a given script, that script is optional.

Server response time still matters. Time to First Byte over about 800 milliseconds is a warning in PageSpeed Insights (it is experimental, not a Core Web Vital).[6] Hosting, redirects, and an overloaded CMS all add wait before the browser can even start the hero. Fast HTML is the floor. It is not the whole job.

A check an owner can run this week

Set aside 30 minutes. You do not need a staging server.

1. Open PageSpeed Insights, paste your homepage URL, and run mobile first. Read the field block at the top (CrUX, last 28 days) before you read the lab score.[6] If field data is missing, the URL may be too new or too low-traffic. Use the origin-level numbers instead.

1. Write down LCP, INP, and CLS at the 75th percentile, plus the share of visits in red. A single green average can hide a large tail of bad mobile visits.

1. In the lab diagnostics, find "Largest Contentful Paint element." If it is a huge image, a cookie banner, or a late-loading card, that is your first fix.

1. Scroll the audits for render-blocking requests, unused JavaScript, and third-party impact. Look for names you recognize from marketing: chat, ads, reviews, tag manager.

1. Repeat on desktop. If desktop is fine and mobile is not, you have a phone problem: oversized images, too much JS, or a hero that is not sized for a small viewport.

1. If you have Search Console, open the Core Web Vitals report and look at URL groups. CrUX is what ranking systems see.[7][8]

1. Do a real-phone test. Load the homepage once, cold. Count seconds until the hero and the primary button are usable. Tap the form. If the keyboard is slow to appear or the layout jumps, you have just felt INP and CLS. That is the lead you are losing.

Then pick one cause. A 400 KB hero, a chat snippet in the `<head>`, or two unused font weights will move LCP and INP more than a week of arguing about a 94 versus 97 lab score.

Fast custom sites are a product choice, not a score chase

We design and ship sites for owners who need the homepage to produce calls and forms, not to win a Lighthouse screenshot. Our web design work covers Forged Sites (custom-built, no CMS login, no plugin stack) and traditional builds when a client actually needs that ecosystem. On Forged Sites we publish the performance target in the open: 100 desktop PageSpeed, 90 or higher on mobile, with an honest caveat that heavy animation or dense media can move the mobile number.[12]

That is Imagine, Design, Forge, Sustain in practice. Imagine the visit on a mid-range phone. Design the first screen so the offer and the action are the LCP. Forge the HTML so the hero is in the first response. Sustain it so a new tag or font does not steal the next quarter's leads.

A slow homepage costs leads even when the brand looks expensive. The visitor does not send a note about Core Web Vitals. They just never become a row in your inbox.

Practical takeaways

• Treat Core Web Vitals as a conversion dashboard. LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 at the 75th percentile of real users, mobile and desktop separate.[1]
• Read CrUX field data in PageSpeed Insights (28 days of Chrome visits) before you react to a lab score.[6]
• Expect the homepage to be slower than inner pages. In 2024 only 38% of mobile home pages had good Core Web Vitals.[10]
• Fix the hero before you tune anything else. Most mobile LCP elements are images, and a late start (not a slow download) is the usual failure.[11]
• Audit third-party tags, fonts, and JavaScript as lead-loss, not as "nice to clean up." They drive INP and often LCP.
• Vintage bounce studies (2017) and later LCP case studies (2020 to 2022) all point the same way: delay kills form starts. Date the study, then act on the pattern.[2][3][4][5]
• Do not chase a perfect SEO score. Google says as much. Ship a homepage that paints, responds, and stays still.[8]

How we can help

Have more questions or want to get in touch? If your homepage is losing the first two seconds, we will look at the field data with you and tell you whether the fix is the hero, the tags, or the stack. Start with our web design page, or go straight to contact and send the URL. We will treat speed as a lead problem, because that is what it is.

Citations

1. web.dev, "Web Vitals" (updated 2024-10-31)
2. Think with Google, "Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed" (2017-02)
3. web.dev, "Milliseconds make millions" (2020-06-24)
4. web.dev, "Vodafone: A 31% improvement in LCP increased sales by 8%" (2021-03-17)
5. web.dev, "Luxury retailer Farfetch sees higher conversion rates for better Core Web Vitals" (2022-07-12)
6. Google for Developers, "About PageSpeed Insights" (updated 2024-10-21)
7. Chrome for Developers, "Overview of CrUX" (updated 2024-02-08)
8. Google Search Central, "Understanding page experience in Google Search results" (updated 2025-12-10)
9. web.dev, "Interaction to Next Paint (INP)" (updated 2025-09-02)
10. HTTP Archive Web Almanac, "Performance | 2024 | The Web Almanac" (2024-11-11, updated 2025-02-04)
11. web.dev, "The most effective ways to improve Core Web Vitals" (updated 2024-10-31)
12. IDFS AI, "Forged Sites" (verified 2026-09-03)