What a 90+ PageSpeed Score Actually Takes on a Kitchen Website

A 90 plus score on a kitchen website comes down to four things: photographs that were prepared for the web instead of uploaded straight off the camera, third-party scripts that load after the page instead of in front of it, fonts and layout that do not shift under the guest thumb, and a page that was built without carrying code it never uses. Everything else is detail. Kitchen sites are a specific case because the content that sells the food is also the content that slows the page, so the work is not stripping photography out. It is shipping the same photography in a form a phone on a weak connection at dinner time can actually render before the guest gives up and reopens a delivery app.

What Core Web Vitals actually measure

Core Web Vitals are three numbers describing what a page feels like to a person holding a phone. Google documents them as measurements of loading, interactivity and visual stability, assessed at the seventy fifth percentile of real page loads, which is a precise way of saying the target is your slower visits rather than your best one. That detail matters for a kitchen, because your slower visits are your dinner rush.

Here is each one in kitchen terms.

Largest Contentful Paint is the wait before the biggest thing on the screen appears. On a kitchen page that is almost always a plated hero shot or a headline sitting over one. Until it paints, the guest is looking at an empty rectangle wondering whether the page is broken. Google documents a good LCP threshold of two and a half seconds, measured at that same seventy fifth percentile.

Interaction to Next Paint is the lag between a tap and any visible response. Guest taps Order, and nothing changes for a beat. The documented good threshold is two hundred milliseconds, which is fast enough that a person experiences the response as instant rather than as a delay they have to interpret.

Cumulative Layout Shift is how much the page moves while it is still loading. A photo arrives late with no reserved space, pushes the menu down, and the thumb that was about to tap a dish taps a phone number instead. The documented good threshold is a score of zero point one or below.

What each one feels like at the pass

Core Web Vital	What the guest experiences	Usual cause on a kitchen site
Largest Contentful Paint	A blank screen where the food photo should be, long enough to wonder if the page loaded	A full-resolution hero photo served at camera size, or a hero image marked for lazy loading
Interaction to Next Paint	Tapping the ordering button and getting nothing back for a beat, then tapping it again	Third-party ordering, chat or analytics scripts occupying the main thread while the guest is trying to use the page
Cumulative Layout Shift	The menu jumps down as a photo loads, so the tap lands on the wrong item	Images and embeds with no reserved dimensions, plus late-swapping web fonts

The reason to think about them as felt experiences rather than scores is that it tells you where to look. A guest complaint that the site “feels slow” almost always maps to one of these three rows, and which row it is determines whether the problem is an image, a script or a missing dimension.

Why the score is not the goal

The score is a proxy. A page can score well and still be unpleasant, and a page can score slightly under while feeling fine. What the three vitals are proxies for is whether the guest gets to the menu and the ordering button without friction, which is the only thing that pays. Chasing the last few points of a lab score while the real dinner-rush experience stays slow is the same energy as polishing the pass while tickets pile up on the rail.

That said, the threshold is a useful line to hold. Below it, the problems are usually real. Above it, further work has diminishing returns and attention is better spent on what the page says.

Food photography: the first culprit, and how to handle it

Food photography is the usual reason a kitchen page is slow, because it is the one asset nobody is willing to cut and the one most likely to be uploaded exactly as it came out of the camera. A single plated hero can outweigh every other file on the page. It is also, by definition, the Largest Contentful Paint element on most kitchen pages, so its download time is the guest wait time.

The fix is not fewer or smaller-looking photos. Guests order with their eyes and a kitchen site with weak photography loses for a different reason. The fix is preparing each image properly, which is five separate habits, not one setting.

Always set width and height

Every image needs explicit dimensions in the markup, even when the display size is controlled by the stylesheet. The dimensions let the browser reserve the right amount of space before the file arrives, which is the single most effective fix for layout shift on an image-heavy page. Without them the browser does not know how tall the photo will be, so it collapses the space to nothing and then pushes everything down when the image lands.

On a menu page with a photo per dish, missing dimensions compound: each image that arrives pushes the rest of the list further down, and a guest scrolling while that happens has the content slide out from under their thumb repeatedly.

Serve modern formats

Modern image formats produce substantially smaller files than older ones at the same visual quality, which is the cheapest speed win available on a photo-heavy page. Serve the modern format with a fallback so older browsers still get an image. The important part operationally is that this happens at build or upload time, automatically, rather than depending on someone remembering to convert a file before adding a dish.

Serve responsive sizes

A phone should download a phone-sized image. Serving one large file to every device means the smallest screens on the weakest connections download the biggest file, which is exactly backwards from what your traffic looks like. Responsive sizes mean generating several widths of each photo and letting the browser choose. Again, this should be automatic. Any process that relies on a person picking the right export size will drift within a month of launch.

Lazy load below the fold

Images further down the page should load as the guest approaches them rather than all at once. MDN documents lazy loading as a strategy for deferring resources that are not immediately needed, and the browser-native attribute makes it a one-word change per image. On a menu page with dozens of dish photos, this is the difference between downloading the whole menu before the first dish appears and downloading the first few.

Never lazy load the LCP image

This is the mistake worth calling out on its own, because it is committed most often by people who just learned about lazy loading and applied it everywhere. Marking the hero image as lazy tells the browser to deprioritise fetching the exact element the guest is waiting for. The result is a page that scores worse after the optimisation than before it.

The rule is simple. Anything visible when the page first paints loads eagerly, and the hero image should be hinted as high priority. Everything below that point loads lazily. If you are not sure where the fold is on a given device, the safe version is to load the first image eagerly and lazy load the rest.

A short photo pipeline that survives a busy kitchen

1. Shoot or receive the photo at full resolution and keep that original in one folder, untouched, as the master.
2. Crop once to the aspect ratio the page uses, so the same dish does not need recropping each time it appears.
3. Let the build process generate the modern format and the responsive widths automatically from the master.
4. Confirm the markup carries width and height for every image, including ones added later by whoever updates the menu.
5. Load the hero eagerly at high priority and lazy load everything below it.
6. Re-check after any menu update, since a new dish photo added by hand is the most common way a tuned page regresses.

The reason to write this down as a pipeline rather than a checklist is that menus change. A page that was fast at launch and slow six months later is almost always a page where somebody added dish photos by hand. The relevant part of what we build is described on the features page, which covers how images are handled so this does not become a manual step somebody has to remember mid-shift.

Third-party scripts: the second culprit

Third-party scripts are the second reason kitchen pages are slow, and they are more insidious than images because the weight is not visible in the page source. An embedded ordering widget, a reservation tool, a review carousel, a chat bubble, a tag manager and two analytics snippets each fetch code from someone else’s server, and each one can hold up rendering or occupy the main thread while a guest is trying to tap something.

Why they hurt more than their file size suggests

A script loaded in the page head blocks rendering until it downloads and executes, which means the guest waits on a third party you do not control before seeing your own content. A script that runs long tasks after loading occupies the main thread, and a thread busy running someone else’s code cannot respond to a tap, which is exactly what Interaction to Next Paint measures. An embed that inserts itself into the layout after it loads pushes your content down, which is Cumulative Layout Shift.

So one carelessly added widget can degrade all three vitals at once. That is why an audit that only compresses images often produces a disappointing result.

How to load them without blocking

Four habits cover most of it.

1. Defer everything that is not needed for the first paint. A widget the guest interacts with after reading the menu does not need to load before the menu renders.
2. Reserve the space the embed will occupy, with a fixed height container, so the layout does not move when it arrives.
3. Load on interaction or proximity where possible. A chat bubble can load when the guest taps the chat button. A review carousel can load when the guest scrolls near it. A map can load when the guest asks to see it.
4. Count them honestly. Most kitchen sites accumulate scripts through experiments nobody switched back off. If nobody has looked at the data a script produces in months, it is not paying its cost.

The ordering embed specifically

The ordering embed is the one script you usually cannot defer into the far distance, because it is the conversion. Even here, the useful distinction is between the button and the widget. The button that opens ordering is your own markup and costs nothing. The widget behind it is third-party code that can load when the guest commits to ordering rather than while they are still deciding what to eat.

Where a platform offers both a link and a full embed, the link is almost always faster and often converts equally well, because the guest ends up in the platform’s own flow either way. The embed earns its weight when it keeps the guest on your site through checkout and you have a reason to want that. Weigh it as a trade rather than installing it because it was offered. This is a large part of what a redesign engagement actually resolves, since inherited sites tend to carry several ordering integrations from platform relationships that ended a year ago.

Fonts and layout shift

Fonts cause the layout shift people notice without being able to name. The page renders in a fallback typeface, the web font arrives a moment later, and every line of text reflows as the metrics change. On a menu, that means dish names and prices shuffle while the guest is reading them.

Three practices keep it contained. Load a small number of font files rather than a family of weights the design never uses. Use a fallback stack whose metrics are close enough to the web font that the swap does not resize the text block dramatically. And let text render immediately in the fallback rather than holding it invisible while the font downloads, because invisible text is a worse experience than a font swap.

Two display weights and two body weights cover almost any kitchen site. Every additional weight is another file on the critical path for a visual difference most guests never register.

Reserve space for everything, not just images

The general principle behind both the image and the font advice is that anything arriving late needs its space held in advance. That includes banners, cookie notices, promotional strips, embedded video thumbnails and any element inserted by a script. If an element will exist after the page settles, the layout should account for it before it arrives.

A useful test costs nothing: load the page on a throttled connection and watch the top of the screen while it settles. Everything that jumps is a shift a guest experiences on a weak signal in a lift.

Why lab scores and field data disagree

Lab scores and field data disagree because they measure different things. A lab score is one simulated load on a modelled device and connection, run when you ask for it. Field data is real loads from real visitors on their own phones and networks, gathered over a rolling window and reported at that seventy fifth percentile.

For a kitchen, those two populations diverge sharply. Your guests order at dinner time, frequently on older phones, sometimes on congested mobile networks in an apartment lobby. Your lab test runs on a modelled mid-tier device with a clean connection. A page can pass in the lab and fail in the field because the lab never simulated the conditions your actual dinner rush runs under.

The practical position is straightforward. Use the lab score to diagnose, because it is repeatable and it names specific problems: this image is the LCP element, this script blocked rendering, this element shifted. Use the field data to decide whether the site is actually fine, because it reflects the guests you have. When they disagree, the field data wins.

Interaction data needs real traffic

One more asymmetry worth knowing. A lab run cannot meaningfully measure interaction responsiveness, because there is nobody tapping anything. Interaction to Next Paint is a field metric in practice, which means a page with heavy scripts can look clean in a lab report and still feel unresponsive to a guest stabbing at an ordering button. If guests report that the site feels sticky and your lab score is high, look at scripts and look at field data rather than concluding the complaint is wrong.

What a page builder does to all of this

A builder-based site carries structural weight that image compression cannot remove. The builder ships the code required to render every layout feature it supports, whether this page uses them or not, because it cannot know in advance which ones a page will use. Each plugin adds its own code on top. The result is a page where a meaningful share of the bytes exist to support features that are not on the screen.

That matters for the three vitals in specific ways. The extra code delays first paint, which hurts Largest Contentful Paint. It occupies the main thread, which hurts Interaction to Next Paint. Builder-generated markup frequently omits image dimensions, which hurts Cumulative Layout Shift. And the parts causing the problem sit inside tools you do not control, so the available fixes are disabling features, removing plugins and compressing images.

Those fixes are real and worth doing. They also run into a ceiling that is a property of the approach rather than of your configuration. A custom-coded page ships the code that page needs and nothing else, which is why it starts near the top of the range instead of climbing toward it. The ghost kitchen build described on /services/ghost-kitchen-website-design is built this way for exactly that reason, and the plan-level detail of what is included and maintained sits on pricing.

If you are stuck on a builder for now

Do the reachable things in order of return. Compress and resize every image, starting with the hero. Remove plugins nobody uses, checking one at a time. Cut the font weights down. Defer the scripts that can be deferred. Delete the second and third analytics tools. Then measure the field data and decide whether the remaining gap justifies a rebuild or whether the site is good enough for now. That is an honest answer more often than people expect.

An audit sequence an operator can run alone

You can diagnose most of this yourself in about twenty minutes without any specialist tooling. Run it in this order, because each step narrows what the next one is looking for.

1. Open your own site on your own phone, on mobile data rather than the kitchen wifi, and time how long it takes before you can read the menu. This is the only test that never lies.
2. Run PageSpeed Insights on your home page and on your busiest menu or brand page. Note both the field data section and the lab score, and keep them separate in your head.
3. Find the element the report names as the Largest Contentful Paint element. It is usually the hero photo. Check its file size and whether it is marked for lazy loading.
4. Look at the layout shift section and note which elements shifted. Check whether each one has explicit dimensions.
5. List every third-party script the report attributes time to. Write down what each one does and whether anyone has used its output recently.
6. Load the page with the connection throttled in your browser developer tools and watch the top of the screen settle. Note everything that jumps.
7. Tap the ordering button as soon as the page renders and see whether it responds immediately or after a beat.
8. Repeat the whole sequence on a menu page with many dish photos, since that page usually behaves worse than the home page.
9. Write the findings down as a list of specific elements, not as a score. “Hero photo is large and lazy loaded” is actionable. “Score is sixty four” is not.

That list gives you the conversation to have with whoever maintains the site, in terms concrete enough that the answer cannot be a general reassurance. It also tells you quickly whether you have an image problem, a script problem or a structural problem, which are three different projects with three different costs.

What this is worth to a kitchen specifically

Speed matters more for a delivery brand than for a restaurant with a dining room because of where the guest is standing when they load the page. They are not walking past your window. They are on a phone, at home, hungry, with a delivery app one tap away, and the page is competing against the lowest-friction alternative in their pocket. A blank rectangle where the food photo should be is a guest who reopens the app.

None of this requires the site to be ugly or the photography to be thin. It requires the photography to be prepared, the scripts to be counted, the fonts to be restrained and the layout to hold still. Those are maintenance habits more than technical achievements, which is why the sites that stay fast are the ones where the habits are built into the process rather than performed once at launch and then quietly undone by the next menu update.

If you want to know what your current site is actually doing at dinner time rather than what a score says on a clean connection, booking a demo is the fastest way to walk through your own pages, your own photos and your own embedded ordering setup against the three vitals rather than against a generic checklist.