Speed & Mobile

Speed and mobile are the same conversation. 71% of restaurant Google traffic comes from a phone, and Google’s “mobile first” index has been the canonical one since 2021 — the desktop version of your site is a courtesy, the mobile version is the product. The math is simple and unkind: every second of LCP costs you roughly 7% of would-be visitors who bounce before the page is interactive, and Google demotes you in the local pack on top of that.

The good news: speed is the single most fixable side of an independent restaurant website. Three numbers do most of the work — LCP (largest contentful paint), CLS (cumulative layout shift), INP (interaction to next paint) — and three patterns cause 80% of regressions: heavy hero photos, render-blocking JavaScript, and fonts that arrive after first paint. Fix those three, run Lighthouse, ship.

The three Core Web Vitals, in plain English

Core Web Vitals is the name Google gives to its three measurable user-experience metrics. Each has a “good” threshold; missing any of them on the 75th-percentile of your real visitors costs you ranking points in the local pack and the regular SERPs.

• LCP ≤ 2.5s. Largest contentful paint — how long until the biggest visible thing on the page (usually your hero photo) finishes rendering. The launch plan’s gate is stricter (≤2.0s) because the site targets the upper-quartile, but Google’s “good” band starts at 2.5. Below 2.5s you’re in the green; above 4.0s you’re in the red and visibly losing visitors.
• CLS ≤ 0.1. Cumulative layout shift — how much things jump around on the page after first paint. The most common cause: images without explicit width/height attributes. The fix: set width and height on every img and use aspect-ratio in CSS. The launch plan’s gate is ≤0.05 because the visual feel is the brand.
• INP ≤ 200ms. Interaction to next paint (replaced FID in March 2024) — how long the page takes to respond to a tap. INP is the killer for tools and reservation widgets; if your “Book a table” button takes 400ms to react, the visitor double-taps and starts a duplicate reservation flow. The fix: defer non-critical JS, code-split, and avoid main-thread blocking from third-party widgets.

You can read your CWV in three places: PageSpeed Insights (synthetic + 28-day field data from real Chrome users), Search Console’s “Core Web Vitals” report (field data only, but reported by URL group), and Plausible if you’ve hooked up web-vitals client-side. The free Speed Test tool runs the synthetic version on any URL.

Why mobile is different

Mobile isn’t just “the same site, smaller screen.” The mobile network is slower, the CPU is weaker, the battery’s a constraint, and the visitor’s context is “I’m walking, hungry, three blocks away.” Three implications:

• Network speed is the constraint. Lighthouse’s mobile preset simulates Slow 4G — ~1.6 Mbps with 150ms RTT and 4× CPU throttle. That’s the ceiling, not the floor. The DMV’s mobile reality (across the four major carriers) is roughly Slow 4G during commute hours, near-LTE on weekends. Build for the worse case.
• Hero images are the leak. The 4MB plate-of-pasta photo that loads in 200ms on your office wifi takes 6 seconds on Slow 4G. Switching to AVIF + WebP fallbacks drops that to 200KB without losing visible quality. The photo spec sheet covers the file-size targets.
• Mobile UX is one column. Two-column hero layouts that look elegant on a 14” laptop become unreadable stacking on a 360px phone. Build the mobile layout first, expand to desktop. Hours block above the hero. Reservation button as a primary-color band. Menu sections collapsible.

The 80/20 of speed work

The five fixes that carry 80% of typical restaurant-site speed gains, ranked by hour-spent-to-LCP-recovered:

1. Compress and re-encode the hero image (15 minutes). AVIF first, WebP fallback, JPEG as the last resort. Target: under 200KB at 1600×1067. Tools: Squoosh, ImageOptim, or the AVIF support built into modern image-CDNs (Cloudinary, ImageKit). Single biggest LCP improvement on most independent restaurant sites.
2. Set width/height on every image (30 minutes). Eliminates CLS jumps. Use the natural aspect ratio of the source image; CSS aspect-ratio on the parent if the image is responsive. The photo spec sheet lists every image surface and its aspect ratio.
3. Defer non-critical JavaScript (1 hour). Add defer to script tags that aren’t needed for first paint. Reservation widgets (OpenTable, Resy, Tock), analytics, chat embeds. Plausible is already async · cookieless · tiny; most third-party tags are not.
4. Self-host fonts with font-display: swap (1 hour). Web fonts blocking the first paint is the second-most-common LCP failure. Self-host the woff2 files, use font-display: swap, preload the two critical above-the-fold weights.
5. Lazy-load below-the-fold images (15 minutes). loading="lazy" attribute on every img below the hero. Saves 40–60% of total bytes on a typical menu page where the visitor never scrolls past the third dish.

Run the free Speed Test on your URL before and after each fix. The score moves immediately; the field-data signal in Search Console takes 28 days to roll over.

What slows down a restaurant site that nothing else does

Three patterns specific to independent restaurants that don’t apply to most other small-business sites:

• Reservation widgets. OpenTable, Resy, Tock, and the lesser platforms all ship hefty third-party JS bundles that load before the visitor can book. The newer “direct” or “widgets v2” APIs from each platform are smaller and faster than the legacy iframe embed; switching from iframe to direct typically saves 200–500ms of LCP. How to recover reservations covers the tradeoffs.
• Menu PDFs. Linking a 4MB PDF as the menu “page” means every visitor who clicks waits for the whole PDF to download before seeing anything. The fix is real HTML — use Menu Converter to turn pasted menu text into semantic HTML in two seconds. The $1,500 menu drop-in ships the studio-built styled version.
• Background videos. The autoplaying hero-video pattern that became fashionable circa 2018 carries 8–15MB of JS-decoded video. On mobile, that’s a multi-second LCP killer for a piece of decoration the visitor never asked for. Replace with a single AVIF still and call it done.

What to do this week

Three actions, in order, total time about an hour:

1. Run PageSpeed Insights on your homepage and your menu page. Read the “Core Web Vitals” section. If LCP is over 3 seconds or CLS is over 0.1, you have an actionable problem. Save the result.
2. Run the free Speed Test on the same two URLs. The two reports cross-validate; if they disagree by more than 0.5s on LCP, that’s usually because your hero image is being served from a cache that one tool hits and the other doesn’t. Treat the worse number as truth.
3. Pick the heaviest hero image you have. Re-encode it as AVIF. Drop the file size under 200KB. Replace the <img> src. Re-run both tools. The score moves; the visitor experience changes immediately.

Operators who want the studio-side version: the $499 audit includes the speed walkthrough on Loom; the $1,500 menu drop-in ships a mobile-fast menu page that meets the launch plan’s LCP ≤ 2.0s gate by default; the full-build tiers ship every page under the gate.

Where this topic touches the others

• Conversions & Content — because a fast page is a precondition for a converting page. Most conversion gains compound on top of speed gains.
• Local SEO & Discovery — because Google demotes slow-mobile sites in the local pack. The faster your site, the higher you rank, the more clicks you get to convert.
• Brand & Design — because design choices (large hero, web fonts, custom cursors) often trade against speed. The good designers know the tradeoff explicitly; the great ones make speed part of the brand.

The composite to watch: Lighthouse mobile score. Run it monthly on your homepage and menu page. The trend line is the only metric that matters; absolute numbers fluctuate week to week.