Web hosting for restaurants — The menu page is your slowest page — here is its number

A restaurant site is four assets wearing a design: a menu, tonight's hours, a booking route and a few photographs. Three of them are text and cost almost nothing to deliver. The fourth is where nearly every restaurant site loses its speed.

Diners do not browse. They open the menu, scan for a dish and a price, then either tap through to book or go back to the map. That behaviour makes the menu the only page worth optimising first, and the phone the only device worth testing on.

So the useful question is not which host is fastest in the abstract. It is what your menu page does on a throttled mobile connection, and which part of that figure the server is responsible for. This page works through it in that order.

A scanned menu is one large image with no text inside it. The browser fetches the whole file before it can paint anything, search engines cannot read a dish name out of it, and a screen reader gets nothing at all. Rebuilt as ordinary HTML the same menu becomes a few kilobytes of text that the cache can hold indefinitely.

It changes your working week too. A price edited in a page is live the second you save. A price edited in a PDF is a design job, an export, an upload and a cache purge — which is precisely why so many restaurant menus online still quote last spring's prices.

Re-run the identical test: same page, same throttling profile, three passes, take the median. A single run tells you nothing. If largest contentful paint has fallen and time to first byte sits under 800 milliseconds, the change was real rather than lucky.

Field data lags by roughly a month because it is a rolling window of genuine visits, so check it again after the next menu change rather than the same afternoon. In the meantime a daily backup turns a plugin update that breaks the booking block into a ten-minute restore.