Speed for Mobile Diners: What a Page Waits On

A restaurant page is usually read by someone standing up. They are on a phone, on a connection they do not control, deciding between your menu and the one two doors down, and the page has roughly the patience of a person already slightly hungry. That is a different performance problem from a desktop application, and it has a specific set of causes on restaurant sites in particular.

This is where the seconds actually go, which of them a guest feels, and which fixes survive two years of somebody else updating the site.

The thresholds, and what they are measuring

Before diagnosing anything it is worth being precise about the numbers, because they are frequently quoted loosely.

The three metrics

Web.dev’s Core Web Vitals documentation sets out three, each with a threshold measured at the 75th percentile of real page loads and reported separately for mobile and desktop.

Largest Contentful Paint should occur within 2.5 seconds of when the page starts loading. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should be 0.1 or less.

The 75th percentile matters. These are not averages, and a site that is fast for most people and very slow for a quarter of them will fail, which is the correct behavior: the slow quarter are real guests on real connections.

What LCP actually is

Largest Contentful Paint reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.

On a restaurant page this is almost always one of two things: a large photograph of the room or a dish, or the first substantial block of menu text. Knowing which one it is on your own page is the single most useful diagnostic step available, because it tells you exactly what to optimize and makes everything else secondary.

Field data, not lab data

A speed score generated in a lab test on a fast machine is a useful development signal and a poor description of reality. What matters is what actual visitors experience, on actual phones, on actual connections, which is what field data measures.

The practical implication for a restaurant: check the numbers for the menu page specifically, not for the home page, because the menu page is where people land and it frequently has a completely different profile.

Images: the restaurant problem

Food photography is the reason restaurant sites are heavy, and it is also the reason they are worth visiting. The goal is not fewer images; it is images that cost what they should.

Where the weight comes from

The HTTP Archive Web Almanac’s page weight chapter documents the composition of page weight across the web, and images remain a dominant component of it.

On restaurant sites specifically the cause is usually direct: a photographer delivers files at full camera resolution, and those files are uploaded unchanged. A single such image can outweigh an entire well-built page. Nobody decided to do this; it is what happens when an upload field accepts whatever it is given.

What a correctly served image looks like

Four things together resolve almost all of it.

The image is served in a modern format rather than as an unoptimised original. It is served at several sizes, and the browser is told which sizes exist so it can request the one that fits the screen rather than a desktop-sized file for a phone. It carries explicit width and height attributes so the browser reserves its space before it arrives. And the one image that is visible without scrolling is loaded eagerly, while everything below the fold is loaded lazily.

That last pairing is where restaurant sites most often go wrong in the other direction. Lazy loading applied to the hero image delays the very element LCP is measuring, which makes the metric worse rather than better.

How many photographs a menu page needs

Fewer than it usually has. A menu page is read for its words. Photographs between courses interrupt the reading, push the content down, and add weight to the page a guest is trying to scan.

The pattern that works is a gallery elsewhere, linked from the menu, and a menu page that is text. That is also how a printed menu works, and for the same reason.

Fonts, and the moment the page shows nothing

Typography is the argument for a chef-led site, so the fonts matter. They should not cost the guest the first second of the page.

The failure people actually notice

The visible failure is not the file size. It is a page that shows no text at all for a moment and then shows all of it, because the browser was told to wait for a font before painting.

The guest reads that as the page being slow, and if it happens for long enough, as the page being broken.

The fixes that matter

Limit the number of families and the number of weights within them, because each one is a separate request. Tell the browser to show fallback text immediately and swap the real font in when it arrives, so text is readable throughout. Hint the connection to the font host early so the handshake is not discovered late. And choose fallback fonts whose metrics are close enough to the real ones that the swap does not visibly reflow the page.

The last of those is the step most often skipped, and it is what turns a swap from a jolt into something most guests never notice.

Third-party scripts, and how they accumulate

No restaurant decides to load six third-party scripts. They arrive one at a time, each for a defensible reason.

The usual inventory

A booking widget. A reviews badge. A map embed. An analytics tag. A chat widget somebody trialled. A social feed on the home page. Each was added by a different person at a different time, and no single addition felt expensive.

Web.dev’s third-party JavaScript guidance is direct about why the total is: these scripts are loaded from servers you do not control, they can block rendering, they compete for the main thread, and their behavior can change without notice.

That last point is the one restaurants underestimate. A third-party script that was fast in March can become slow in September because the vendor shipped something, and nothing on your side changed.

Audit by asking what breaks

The useful audit question is not “is this script slow” but “what breaks if it is not there”.

A reviews badge that displays a rating removes nothing functional if it goes. A social feed showing posts from a channel that has not been updated this year is pure cost. A map embed can be replaced by an address in text and a link to directions, which serves the guest better anyway because it works in every context including a printed page.

What survives that question is usually the booking system and the analytics, and both can be loaded carefully.

Load on interaction

The pattern that resolves the booking widget specifically: ship a real button as part of the page, and load the widget’s script when the button is activated.

Every reader who does not book never downloads it. Every reader who does book waits a moment they were already prepared to wait. Nobody pays for it while reading the menu.

Layout shift is a physical problem

Cumulative Layout Shift measures unexpected shifts of visible page content during the page’s lifespan.

Why it feels different from slowness

Slowness is experienced as waiting. Layout shift is experienced as the page moving under your thumb. On a phone it produces mis-taps, and a mis-tap on a restaurant page frequently means opening the wrong page while trying to book.

The three causes on restaurant sites

Images without dimensions, which take up no space until they arrive and then push everything down. Late-arriving third-party embeds that insert themselves into the flow. And web fonts that reflow the text when they swap in, if the fallback metrics are badly matched.

All three have the same fix in principle: reserve the space before the thing arrives. For images, dimensions. For embeds, a container with a known height. For fonts, matched fallback metrics.

Diagnosing your own page in fifteen minutes

None of the above helps without knowing which of it applies to your site. This is the sequence, and it needs no specialist tooling beyond a browser.

Find the LCP element

Open the menu page on a throttled connection in your browser’s developer tools and look at what the performance panel reports as the Largest Contentful Paint element. It will be a specific image or a specific block of text, highlighted in the page.

That element is the metric. If it is a photograph, the photograph is the work. If it is the first heading of the menu, the work is in whatever is delaying the text, which is usually fonts or a render-blocking script.

This single step redirects more wasted effort than anything else in performance work, because most people optimize what they assume is slow rather than what the measurement names.

Sort the network panel by size

Load the page with the network panel open and sort by transfer size, largest first. The top five rows are your page.

On a typical restaurant site the list reads: one enormous photograph, a booking widget bundle, a map, a font file or four, and an analytics tag. Each of those has a named owner and a known fix, and the list takes two minutes to produce.

Count the third parties

In the same panel, group by domain. Everything not on your own domain is a third party running on your budget.

Write the list down, put a name next to each one for who asked for it, and ask what breaks if it goes. Anything nobody can account for can go today.

Watch the page load at quarter speed

Throttle to a slow connection and watch the load with your own eyes rather than reading a number. You will see, in order: what appears first, how long the text is invisible, and what jumps when it arrives.

That last one is the layout shift, and seeing it is far more persuasive than a score. It is also the fastest way to find an embed that is pushing the booking button down the page half a second after the guest has decided to tap it.

Check the menu page, not the home page

Every one of these steps should be run against the menu page. It is the page people land on, it usually has the most text, and it frequently has a completely different profile from the home page the agency tested.

What holds up after two seasons

Any site can be fast on launch day. The interesting question is whether it is fast after eighteen months of menu changes, new photographs and one more widget.

Make the fast path the default path

If uploading an image at full resolution is possible, it will happen. The durable fix is a system that processes images on the way in, so that whoever uploads the photograph gets the optimized, correctly sized, correctly formatted versions whether or not they know what any of that means.

This is the difference between a performance project and a performance property. A project decays; a property holds.

Keep the page mostly text

The deeper reason a well-built menu page stays fast is that it is mostly text. Text is small, it compresses well, it renders immediately, and it does not get accidentally uploaded at camera resolution.

A site whose most important pages are text with a small number of deliberate images is structurally fast, and stays fast under people who are not thinking about performance at all, which is the normal condition of a working restaurant.

Budget for the third one

The practical governance rule: agree in advance what happens when someone wants to add another third-party script. Not to forbid it, but to make the cost visible at the moment of the decision rather than six months later when the page is slow and nobody can remember why.

Three things that are slower than they look

The home page carousel

A rotating set of full-width photographs is still the default opening of a restaurant website, and it is expensive in a way that is easy to miss.

It loads several large images rather than one. It frequently loads all of them before showing the first. It needs a script to rotate them. And on a phone it occupies most of the first screen with a picture, pushing the one thing the guest came for, some indication of what you cook, below the fold.

A single well-chosen image with a headline beside it costs a fraction as much and says more. If the other photographs are worth showing, they are worth a gallery page that a guest chooses to visit.

The social feed

A live feed of recent posts is a script, a set of network requests to a third party, and a block of content whose height is unknown until it arrives, which makes it a layout shift as well as a weight.

It is also, on most restaurant sites, showing posts from several months ago, which communicates the opposite of the liveliness it was added for. A link to the channel costs nothing and never looks stale.

Video backgrounds

A muted looping video behind a hero is heavier than any image on the page by a wide margin, it competes for bandwidth with the content the guest is waiting for, and on a phone it is frequently either not played at all or played at the cost of the rest of the load.

If the room genuinely needs motion to be understood, a short video the guest chooses to play, with a still image as its poster, delivers it to the people who want it and costs nothing to everyone else.

What we do about it on a managed site

Because we build and run the site rather than handing it over, the performance work is mostly structural rather than periodic.

Images are processed on upload, so whoever adds a photograph gets correctly sized and formatted versions without knowing what either of those words means. The menu pages are text by design, with photography in a gallery rather than between courses. The booking widget loads on interaction rather than on every page view. Fonts are limited in number, swapped rather than blocked, and matched to fallbacks so the swap does not move the page. Everything that arrives late has its space reserved before it arrives.

None of that is a one-time optimization pass. It is a set of defaults that keep a site fast while the people using it think about their kitchen instead of about page weight, which is the only arrangement that survives a real year in a real restaurant.

What speed is and is not

Google describes meeting the Core Web Vitals thresholds as aligning with what its core ranking systems reward. That is a real claim and a narrow one. It is not a promise that a fast site ranks above a slow one, and it should not be sold that way.

The argument that does not depend on any ranking system is simpler. A person standing outside, deciding where to eat, on a phone, will not wait. Every second of delay is a chance for them to go back to the results page where your competitors are listed. That is true regardless of what any algorithm does, it is measurable in the only number a restaurant actually cares about, and it is entirely within your control.