Site Speed on Phones: Why It Books Trips

Speed is a threshold, not a ladder, and understanding that saves guides a great deal of wasted effort. Google publishes three numbers and one assessment rule: the largest thing on screen should appear within 2.5 seconds, a tap should get a response within 200 milliseconds, and the page should not shift around by more than a small amount, all judged at the 75th percentile of real page loads. You either clear those or you do not. Beating a threshold by an extra second buys nothing from the metric, which means the correct goal is to pass and then go do something else. The complication, and the reason so many guides are confused about this, is that the score most people stare at is measured in a simulated environment that cannot measure one of the three metrics at all. What actually goes on the page in the first place is a separate question; this one is about how fast it arrives.

Does speed actually book trips?

Almost certainly, and this article will not quote you a number for it, because the figures that circulate about a one-second delay costing a specific percentage of conversions were not verifiable from a primary source. What is verifiable is what the thresholds are and how they are assessed.

Be suspicious of the statistics on this topic generally. Speed-and-conversion numbers get repeated across marketing pages for years without anybody linking the study, and they usually come from a business unlike yours at a volume unlike yours. If somebody selling you a rebuild leads with one, ask where it came from.

What can be argued without invented data is mechanical. A visitor standing at a boat ramp on one bar of signal, deciding whether to call you, is in a hostile environment for a heavy page. If your site takes six seconds to show anything, some fraction of those people leave, and you will never see them in any report. That is enough of a reason without a fabricated percentage attached.

Clear Lake, TX

What are the three numbers?

Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. Those are the current Core Web Vitals, and they cover loading, interactivity and visual stability.

Google's own Web Vitals documentation states each threshold plainly: LCP should occur within 2.5 seconds of when the page first starts loading, pages should have an INP of 200 milliseconds or less, and pages should maintain a CLS of 0.1 or less.

Translated to a guide site: LCP is almost always your hero photograph. INP is what happens when somebody taps a trip or opens your rates. CLS is the page jumping while an image or a font loads, which on a booking form means somebody taps the wrong thing.

These definitions do get revised, though the documentation notes that stable Core Web Vitals metrics change no more than once a year. Check the current thresholds rather than trusting a page from last season, including this one.

Why is it a threshold rather than a score?

Because the assessment is pass or fail. The guidance is that a page passes if it meets the recommended targets at the 75th percentile for all three metrics. There is no additional credit for being twice as fast as required, and no partial credit for passing two of three.

That 75th percentile detail is the one guides miss and it matters more than the thresholds themselves. It means three out of four real visits have to clear the bar, on the devices and connections your actual visitors have. Your own test on a new phone on home wifi is one data point from the fast end of the distribution.

The practical consequence is liberating. Once you pass, stop. Time spent shaving another 400 milliseconds off a page that already loads in 1.9 seconds is time not spent writing a trip page, and the trip page will do more for your bookings. Knowing when a site is genuinely finished is half of the rebuild question.

Why does my green score not match reality?

Because a lab test and the real assessment are different things, and one of them cannot measure everything. Tools that load your page in a simulated environment without a user cannot measure Interaction to Next Paint at all, because there is nobody there to interact with it.

This is stated directly in the documentation: tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP, as there is no user input, and Total Blocking Time is offered as a lab-measurable proxy. So the score most people optimise is silent on a third of the assessment.

The same documentation is blunt that lab measurement is not a substitute for field measurement, because performance varies with device, network, what else is running, and how somebody interacts with the page. A green lab score on a fast connection tells you the page can be fast, not that it is fast for your visitors.

None of which makes lab tools useless. They are the right tool for catching a regression before you publish. They are the wrong tool for deciding whether your site is actually passing.

Where does the real data come from?

Field data collected from actual Chrome users. The Chrome User Experience Report gathers anonymised real-user measurements for each Core Web Vital, and it is what powers the assessment shown in PageSpeed Insights and in Search Console's Core Web Vitals report.

So when you run a page through a testing tool, look for the section reporting real-world visitor data rather than the simulated score at the top. That is the part answering the question you care about. The CrUX documentation explains what is collected and how.

Two caveats worth knowing before you rely on it. Field data needs enough traffic to report, so a small guide site may show nothing at all, which is not a failure. And it reflects the last month or so rather than the change you made yesterday, so improvements take weeks to appear.

If you want a sense of how heavy the web has become generally, HTTP Archive publishes longitudinal page-weight data. No figure from it is quoted here, because that report renders its charts in the browser and quoting a number I had not read would be inventing one.

Why do guide sites fail specifically?

Photographs, almost every time. A guide business is one of the most image-heavy small businesses there is, and it has the most beautiful raw material and the least reason to compress it. One uncompressed hero shot from a modern phone can be several megabytes on its own.

This is worth stating clearly because it collapses the whole problem into one action. Guides spend money on hosting, platforms and rebuilds chasing a speed problem that is a folder of oversized JPEGs. Fix the images first and measure again before changing anything else.

The reason it goes unnoticed is that the person who uploaded them has them cached. Your site feels fine to you and always will. The visitor loading it cold, on cellular, at a ramp, is having a different experience that you cannot see from your own desk.

Fix one: the hero image

Your largest contentful paint is almost certainly the big photo at the top. Resize it to the size it actually displays at, export it in a modern format, and make sure it is not lazy-loaded, because deferring the one image that defines your LCP makes it later rather than sooner.

Concretely: a hero that displays 1,600 pixels wide does not need to be a 4,000-pixel original. Exporting at roughly the displayed size, in WebP or similar, typically cuts the file by most of its weight with no visible difference on a phone.

The lazy-loading detail catches people who have read half the advice. Deferring below-the-fold images is correct and helpful. Deferring the hero is counterproductive, because you have told the browser to wait before fetching the exact thing being measured.

Choosing which photograph earns that spot is a separate judgement, and a better one than most guides make, which is covered in the piece on trip photos.

Fix two: everything below the fold

Every image the visitor has not scrolled to yet should be lazy-loaded, so it is fetched when needed rather than competing with the content on screen. On a gallery-heavy guide site this is often the single largest remaining win after the hero.

Modern platforms do this by default, which means the common failure is a site built a few years ago, or one where a gallery plugin overrides the default. Worth checking rather than assuming, because the fix is usually a setting rather than work, and which platform you are on changes where that setting lives, as covered in the platform comparison.

Also give every image explicit width and height. That does nothing for load time and everything for layout stability, which is the third metric and the one covered next.

Fix three: the things that move the page

Cumulative Layout Shift measures how much the page jumps while it loads, and the threshold is 0.1 or less. On a guide site the usual culprits are images without dimensions, web fonts swapping in, and a cookie banner or promo bar that appears after everything else has settled.

The reason this matters more than it sounds is the booking path. A visitor reaching for a trip button while the page reflows underneath them taps something else, and a meaningful share of those people do not try again. It is a conversion problem wearing a technical costume.

The fixes are mundane. Set width and height on images so the browser reserves the space, which is also one of the basics in accessibility for guide sites. Reserve space for anything injected late. And reconsider whether the banner needs to be there at all, which on most guide sites it does not. What the booking path should feel like start to finish is set out in the booking page piece.

Fin, FL

Fix four: third-party scripts

Every embedded widget, chat bubble, review carousel, analytics tag and social feed is code from somebody else's server executing on your page. Each one is a dependency on a company whose priority is not your load time, and they are the usual cause of a poor interactivity score.

Audit them by asking what each one earns. A chat widget nobody staffs, a social feed nobody looks at, and three analytics tools where one would do are all common on guide sites and all cost real milliseconds on every visit.

Interaction to Next Paint is where this shows up, because heavy scripts occupy the main thread and delay the browser's response to a tap. If your site feels laggy when somebody presses something despite loading quickly, look here rather than at your images.

What about video?

A background video on a homepage is the single most expensive decoration available, and it is rarely earning its cost. If you keep one, do not autoplay it on mobile, give it a lightweight poster image, and never let it be the largest contentful paint.

The honest question is what the video does that three good photographs do not. On a guide site the answer is usually atmosphere, and atmosphere is available at a fraction of the weight. The visitor deciding whether to call you needs to know where you fish and what it costs.

If the video is genuinely good, put it further down the page where somebody who is interested will find it, and let the top of the page load fast. That ordering respects both audiences.

How do you test it properly?

On a phone, on cellular data, with the site not already cached. Your own phone on your own wifi, having visited the page a hundred times, is the least representative test available and it is the one everyone runs.

The quickest honest version: turn off wifi, open the page in a private window, and count. If you are still waiting at four seconds, you have your answer without any tooling. Then run a proper test for the field data and the specific diagnostics.

Test the pages that matter rather than only the homepage. Your trip pages and your booking page are where the decision happens, and they are frequently heavier than the homepage because nobody has ever looked at them. Building those out properly is covered in the trip pages article.

What do experienced guides do differently?

They resize photographs before uploading, as a habit, forever. That one discipline prevents most of this and costs about thirty seconds per image at the point of upload.

The habit matters more than any one-off fix, because a site that was optimised last spring drifts back as a season of new photographs goes up. Speed is not a project you complete; it is a consequence of how you add things.

They also test on the worst connection they can find rather than the best. A guide who checks their own site from the truck at a put-in with bad signal learns more in one attempt than from any dashboard, and that is the actual condition many of their visitors are in.

What are the common mistakes?

Chasing a lab score instead of the field assessment. Lazy-loading the hero image. Adding a plugin to fix a problem caused by photographs. And rebuilding an entire site to solve something that was four oversized files.

The rebuild mistake is the expensive one and it is often sold. A slow site is usually a content problem rather than a platform problem, and moving platforms carries a real cost in lost search standing while fixing nothing. Compress the images and measure again before anyone quotes you for a rebuild.

The plugin mistake is its own small comedy: installing a performance plugin, which is more third-party code, to compensate for images that could have been resized. Sometimes those tools help. They are never the first thing to try.

What surprises people?

That a lab test cannot measure one of the three metrics. That the assessment is at the 75th percentile of real visits rather than your test. That passing is the whole goal and there is no prize for exceeding it. And that the answer is nearly always photographs.

The lab-versus-field gap explains most of the confusion guides have about this topic. Somebody runs a test, gets a green number, and cannot reconcile it with a site that feels slow on their phone. Both observations are correct; they are measuring different things.

The threshold framing is the more useful surprise, because it tells you when to stop. Once your pages clear the three numbers on real visitor data, further speed work has no measurable return, and the effort belongs elsewhere. Everything else written here about the site itself is gathered on the guide websites hub.

When should you stop?

When the field data shows all three metrics passing at the 75th percentile. That is the finish line as published, and treating it as one is the difference between a site that is fast enough and a project that never ends.

If field data has not accumulated because your traffic is low, use the honest proxy: open the pages that matter on a phone, on cellular, cold, and see whether the wait annoys you. If it does not, you are done for now.

Then go back to the things that actually change bookings, which are what the pages say and whether somebody can book in three taps. Speed is a hygiene factor: failing it costs you, and passing it does not win anything on its own. The catalogue of what else goes wrong is in the common website mistakes.