A common question from small-business owners: “Why does page speed matter? My site loads fine on my laptop.” The follow-up that drives the question is the one that doesn’t get said out loud — is it worth the money to fix.

This post walks through the math on a hypothetical restaurant — a 70-seat place doing about $90,000 a month in revenue, with online ordering and reservations through the website. The specific numbers are illustrative; if your restaurant is bigger or smaller, scale linearly. The methodology is what matters.

What “page speed” actually means

When developers say “page speed,” they usually mean a few specific things measured by Google’s Lighthouse audit:

• Time to First Byte (TTFB): how long after a customer taps your link before any response starts coming back. Google flags anything over 600 ms as needing improvement.
• First Contentful Paint (FCP): how long until the customer sees anything on screen — usually the background color and the header. Google’s “good” threshold on mobile is under 1.8 seconds.
• Largest Contentful Paint (LCP): how long until the main content is visible. This is usually your hero image or the menu headline. Google’s “good” threshold on mobile is under 2.5 seconds; over 4 seconds is “poor.”
• Cumulative Layout Shift (CLS): how much the page jumps around as it loads. A page where the text shifts down when the hero image loads is annoying enough that people leave.

You don’t need to memorize these. You just need to know that the difference between a 4.5-second LCP and a 1.5-second LCP is the difference between a customer who orders dinner and a customer who switched to the next tab.

Where a typical small-restaurant site sits

Run the Lighthouse audit on the mobile homepage of most small-business restaurants and the report tends to look like this:

• LCP between 3.8 and 8.2 seconds
• TTFB between 800 ms and 2.4 seconds, because most are hosted on shared WordPress, Squarespace, or Wix
• Hero images between 2 and 7 MB, uncompressed JPEGs straight from a phone or DSLR
• A blocking script for the reservation widget that adds a second or more on its own
• A menu that’s a PDF, which on mobile either triggers an in-browser PDF viewer (slow) or a download prompt (worse)

Lighthouse mobile performance score on a site like this almost always lands below 50. Google considers 90+ to be “good.”

How many visitors a slow site loses

Google’s most-cited research on this is the 2017 “Find Out How You Stack Up to New Industry Benchmarks for Mobile Page Speed” report. The headline numbers are framed as relative increases in bounce probability:

• 1s to 3s load time: probability of mobile bounce increases 32%
• 1s to 5s: increases 90%
• 1s to 6s: increases 106%
• 1s to 10s: increases 123%

A separate 2019 study from Portent looked at conversion rather than bounce, and found that conversion rates drop an average of 4.42% for every additional second of page-load time between 0 and 5 seconds. That is the steepest drop of the load-time curve — every second of latency in the first five matters more than seconds 5 to 10.

Apply that conservatively to a site loading the hero in 4 seconds versus 1 second: roughly 13% fewer engaged visitors convert on the slow site, before you count the additional visitors who bounced before the page even loaded.

Putting numbers on the illustrative restaurant

Assume the 70-seat restaurant gets roughly 4,000 monthly mobile visitors during the dinner-decision window — people on phones deciding where to eat. That’s reasonable for a place doing $90K a month in food and beverage.

Take a baseline mobile bounce rate of 35% on a fast 1-second site, and apply the Google figure of a 32% relative increase in bounce probability when load time stretches to 3 seconds. The slow-site bounce rate works out to roughly 46%. The difference between fast and slow nets roughly 440 more engaged visitors per month on the fast site.

If 6% of engaged visitors convert to a reservation, online order, or phone call (an illustrative rate — your real number depends on your business), that’s roughly 26 additional monthly conversions on the fast site. At an average ticket of $58 (entrees + drink + tip for two), that’s about $1,500 in additional monthly revenue from the speed fix alone.

That number depends on the assumptions above. If your traffic is double, double the answer. If your ticket size is half, halve it. The structure is what matters: every second of latency on a phone costs you a measurable share of visitors, and the dollars are not theoretical.

Where the speed actually comes from, and what each fix moves

Three changes typically take a small-restaurant site from a 4–5 second LCP to a 1.5–2 second LCP. In rough order of impact:

1. Move off shared WordPress or builder hosting. Shared hosting with WordPress, Squarespace, and Wix all have baseline TTFB in the 800ms–2s range, because the request has to wake up a PHP process or hit a cold CDN edge. A static-first build deployed to a modern edge platform (Cloudflare Workers, Vercel Edge, Netlify) has TTFB under 200 ms globally. This single change usually drops total LCP by 1.5 to 2.5 seconds.

2. Compress the hero image and serve modern formats. A 4 MB JPEG hero image takes 3 to 6 seconds to download over typical mobile cellular. The same image at the resolutions actually displayed on a phone, exported as WebP or AVIF, is 100–250 KB and downloads in under 300 ms. This is the single highest-impact one-shot fix on most sites.

3. Replace the PDF menu with a real HTML menu. PDFs render slowly on mobile. The file is usually 2–5 MB, the in-browser viewer blocks the main thread, and there’s no way to make individual items linkable, searchable, or visible to Google. A real menu page is faster, accessible, indexable, and editable without paying a designer for every change.

Bonus pass: a reservation widget that doesn’t open in a popup or iframe. Default OpenTable and Resy widgets are heavy and add a step. A first-party reservation form posting directly to your booking system is faster to fill and tends to convert better.

The non-restaurant version

The math above is restaurant-specific because the numbers are easy to make concrete. The principle is general. For any small business where customers find you on mobile and make a decision in under a minute:

• A 2-second improvement in LCP recovers roughly 10–20% of would-be mobile bounces in typical cases — the exact share varies by site and audience.
• Each recovered visitor converts at your existing rate, typically between 1% and 6% by industry.
• The dollar value of those conversions varies, but it is almost never zero, and it is almost always higher than the cost of fixing the speed problem.

For a roofing contractor whose average job is $7,500 — recovering 5 leads a month that close at 25% is over $9,000 in monthly revenue. For a dental practice whose average new-patient lifetime value is $1,200 — recovering 8 inquiries a month that close at 40% is nearly $4,000.

Speed work usually pays for itself within the first 30 to 60 days for any small business with meaningful web traffic. The reason most owners haven’t fixed it is that their developer hasn’t told them.

What you can do without calling anyone

Open pagespeed.web.dev on your phone. Paste your homepage URL. Pick “Mobile.” Wait 30 seconds.

You’ll get a score from 0 to 100 and a specific list of issues. If your score is below 70, you’re likely losing meaningful monthly revenue. If it’s below 50, you’re losing a lot.

The specific issues in the report — “properly size images,” “eliminate render-blocking resources,” “reduce server response time” — are the same list any competent developer would work from. You can hand them this list. A competent developer will look at it and tell you which fixes are easy and which are structural. An incompetent one will tell you “those don’t really matter.” That second response is a sign to find a different developer.

If you’d rather we look at it together, book a 30-minute call — we’ll walk through your site, talk about where you’re likely losing the most leads, and send you a written estimate of what each fix would cost and what it would likely return.

Restaurant-specific build details are here if you want to see what a properly engineered restaurant site looks like out of the gate.