A digital menu that loads before the drinks do

A guest sits down, scans the code on the table and waits. The page is white. A spinner turns. A large photograph of the dining room appears, slowly, line by line. The guest, who only wanted to see the wine list, puts the phone down and looks for a server. By the time the menu has loaded, the drinks the guest would have ordered from it could already have arrived.

A digital menu has to be fast, because guests open it at the exact moment they want to order and have no patience for waiting. It also has to be easy to read and easy to find things in, on a small screen, often in dim light, often on a weak signal. This guide covers how fast a digital menu should load, how to keep it light, the three taps rule, legibility on a phone, and what to do for guests with a weak signal or no data at all. Every figure in it is an example.

Guests open a digital menu at a moment of intent. They have just sat down, they are hungry or thirsty, and they want to see what is on offer. Every second of waiting at that moment feels longer than it would at home, scrolling at leisure.

Slow menus have a cost. Guests who give up on the digital menu ask a server instead, which takes the server's time. Guests who wait for a slow menu are already slightly irritated when they order. And guests who had a slow experience once are less likely to scan the code on their next visit.

Speed also shapes how the menu is used during the meal. A menu that opens instantly invites guests to look again for dessert or another drink; a slow one does not.

There is no exact rule, but the principle is simple: the menu should be readable before the guest has time to wonder whether it is working. In practice, that means something useful on screen within a second or two, and the menu itself usable within a few seconds, on an ordinary phone and an ordinary mobile connection.

The general study of how quickly pages load and respond, often called web performance, offers plenty of measures, but a venue does not need them all. What matters is how it feels at the table: does the menu appear quickly at the back of the dining room, on a guest's phone, on the evening's mobile signal?

Test it there. Sit at the table furthest from the router, switch off wifi and open the menu on mobile data. Count the seconds. That is your guests' experience.

Most slow digital menus are slow for the same few reasons.

Each of these can be fixed, and fixing the biggest one often makes the most difference. Images are usually the first place to look.

A light digital menu loads only what the guest needs, when they need it. Photographs are resized to fit a phone screen and compressed, so each is a small fraction of its original size. Photographs further down the menu load as the guest scrolls to them, rather than all at once.

The first screen should be the menu, or a clear way into it, not a large welcome image. The venue's name, the sections and the first dishes are what guests want to see. A small logo is enough branding.

Avoid PDFs entirely for the digital menu. A PDF is a picture of a paper menu: heavy to download, slow to open and hard to read on a phone. Our guide to the menu on your website, not in a PDF covers why a live menu page is better in every way.

Speed is not only about loading; it is also about how quickly a guest can find what they want. A useful rule of thumb is that a guest should be able to reach any dish within about three taps: one to open the menu, one to choose a section and one to open the dish.

That rule shapes the menu's structure. Sections should be few enough to show at the top of the screen, with clear names guests understand. Sections should be reachable in one tap from anywhere, not only by scrolling past everything above them. A search box helps guests who know what they want go straight to it.

Count the taps yourself. How many does it take to find the house red, a vegetarian main or the dessert you most want to sell? If the answer is more than three or four, the structure needs work.

A digital menu is read on a small screen, often held at arm's length, often in dim light. Text that is easy to read on a desktop monitor can be a struggle at the table.

Use text large enough to read without zooming, in a clear typeface, with strong contrast between text and background. Avoid light grey text on white and white text on busy photographs. Keep descriptions short, because long paragraphs are hard to read on a narrow screen.

Some venues offer a dark version of the menu for dim dining rooms, which can be easier on the eyes at night. Whatever the look, test it at a table in the evening light, not in the office at noon. Our guide to QR menu design that is not a PDF on a phone covers the design choices in detail.

Guests use a digital menu with their thumb, often with one hand, while talking to the people they are with. Menu design for the thumb means large, well-spaced buttons, important controls within easy reach, and nothing that needs precise tapping.

Section tabs at the top should be large enough to tap without hitting the wrong one. Buttons to add a dish, choose an option or open details should be generous. Pop-ups that need closing with a tiny cross in the corner should be avoided altogether.

The same principles apply to booking pages and ordering pages. Our guide to mobile booking: thumbs, not mice covers them for booking, and nearly all of them apply to the menu too.

Photographs help guests choose, but they are also the heaviest part of a digital menu. A menu with a large photograph for every dish can be beautiful and slow.

Use photographs where they help most: the dishes you most want to sell, dishes that are hard to imagine from a description and dishes that look appealing. Make each one small enough to load quickly, cropped so the dish fills the frame. A photograph that takes three seconds to appear does more harm than good.

Keep photographs honest. A photograph of a dish that looks nothing like what arrives disappoints guests, however quickly it loaded.

Not every guest will have a good signal. Basements, old buildings with thick walls, rural venues and crowded events can all leave guests with a weak connection or none at all. Some guests have no mobile data, or prefer not to use it.

Plan for them. If you offer guest wifi, make it easy to join, with the name and password printed near the code or on the table. Keep the menu light enough to load on a weak connection. And always have an alternative: a paper menu on request, or a server ready to help.

Test the worst spots in the venue. If the corner table never gets a signal, that table needs a paper menu every time, or a better wifi signal.

A digital menu's great advantage over paper is that it can change in seconds: a dish sold out, a price changed, a special added. But that only helps if updating a QR menu is quick and actually happens during service.

Make updates easy for the team. A dish that sells out should disappear from the digital menu, or be marked sold out, the moment the kitchen says so, ideally from the same screen the team already uses to take orders. A menu that still offers a dish the kitchen ran out of an hour ago frustrates guests and servers alike.

Keep the digital menu in step with every other version. Our guide to updating the menu in one place, not five covers how to make one change reach every menu at once.

Speed starts before the menu loads, with the code. A qr code menu reached through a long chain of redirects, or a link shortener, adds seconds before anything appears. The code should open the menu directly.

The code should also open the right page: the menu, not the venue's home page, and, where guests order from the table, the menu for that table. A guest who scans and lands on a page asking them to choose a venue or a table has an extra step before they can read anything.

Our guide to the table QR code: sticker, stand or menu card covers placing and labelling codes so guests find them.

The digital menu is often one of several pages guests use: the booking page before they arrive, the menu at the table, perhaps a payment page at the end. Each one should be as fast as the menu, because a slow step anywhere spoils the experience.

Booking page speed matters especially, because a guest who gives up on a slow booking page may book somewhere else. The same causes, heavy images, too many scripts and pages that try to load everything at once, slow booking pages just as they slow menus, and the same fixes apply.

Test the whole journey on a phone, from finding the venue to booking, ordering and paying, and note every moment of waiting.

Once the menu is fast, watch how guests use it. Many digital menu systems show how many guests open the menu, which sections they visit, which dishes they look at and how far down they scroll. Those figures show whether guests find what they want quickly.

If many guests open the menu and few go beyond the first section, the structure or the first screen may be the problem. If guests look at a dish often but rarely order it, its description, photograph or price may need work. If guests search for things the menu does not have, the menu may be missing something, or hiding it.

Use what you learn to make the menu faster to use, not just faster to load.

A digital menu should work for guests who see, read or use phones differently. Some guests enlarge the text size on their phones; the menu should grow with it rather than break. Some use screen readers, which read the page aloud; the menu should have clear headings, labelled buttons and text descriptions where images carry meaning.

Colour should never be the only way information is shown. A dish marked vegetarian only by a green dot is invisible to a guest who cannot tell green from grey; a letter or a word as well as the colour works for everyone. Test the menu with the phone's own accessibility settings switched on.

Guests reading a menu on a phone are often distracted, in a noisy room, glancing between the screen and the conversation. Plain words help everyone: short dish names, short descriptions, familiar names for sections such as starters, mains and desserts.

Explain unusual terms in the same line rather than expecting guests to know them, and avoid section names that are clever but unclear. A guest who cannot tell what a section contains will often not open it.

Not every guest has a new phone. A menu that runs smoothly on the latest model can be slow, cramped or broken on a phone that is several years old, with a smaller screen and less memory.

Test on an older, smaller phone as well as a new one. Check that text is still readable, buttons are still large enough, nothing overlaps and the menu still loads quickly. A menu that works on the slowest phone in the room works for everyone.

A menu that was fast at launch can slow down over time, as photographs are added, sections grow and new features appear. Check it every few months in the same way: the same table, the same phone, the same mobile connection, counting the seconds until the menu is usable.

If it has slowed, look at what has changed. A new set of large photographs, an extra script or a growing number of dishes is usually the cause, and usually easy to fix.

An invented wine bar's digital menu opens with a full-width photograph of the bar, followed by every section on one long page, with a large photograph beside every wine and every small plate. On mobile data at the back of the room, the menu takes many seconds to become usable, and many guests give up and ask for a paper list.

The bar removes the opening photograph, resizes and compresses every image, and keeps photographs only for its ten best-selling plates. It adds section tabs at the top and a search box, so guests can reach the wines by colour in two taps. It prints the guest wifi details on the table card beside the code.

On the same phone and connection, the menu is now readable in a second or two. More guests use it, servers stop handing out the paper list at every table, and guests begin ordering a second glass from the menu without waiting for a server.

In servearound, the digital menu opens in the guest's browser from the table's QR code or the venue's menu page, with nothing to download. It is a live menu page rather than a PDF, laid out for a phone, with category tabs, search, filters for dietary needs and allergens, photographs where the venue adds them, and each dish's details a tap away. Its look, from typefaces to cards and tabs, is set by the venue and published when it is ready, with each version kept.

Marking a dish sold out on the till shows it as sold out on every guest menu at once, and a menu's schedule decides which menu guests see at each hour. The menu report shows how far each visit gets, how far down the page guests scroll and what they searched for. See the menus module.

Fast enough that guests never wonder whether it is working: something useful on screen within a second or two, on an ordinary phone and mobile connection.

Large images, a heavy opening screen, PDFs, loading everything at once and extra scripts such as pop-ups and trackers.

No. PDFs are slow to load and hard to read on a phone. A live menu page is faster and easier to use.

A rule of thumb that a guest should reach any dish within about three taps: open the menu, choose a section, open the dish.

Use fewer, smaller photographs, for the dishes where they help most, resized for a phone and loaded as the guest scrolls.

Offer easy guest wifi, keep the menu light, and always have a paper menu or a server ready as an alternative.

The moment the kitchen says so, ideally from the same screen the team uses to take orders.

Yes. A slow booking page can cost bookings, and the same causes and fixes apply as for the menu.

Watch how far guests get, which sections they visit, what they search for and which dishes they look at but do not order.

A digital menu has to load before the guest's patience runs out, because guests open it at the moment they want to order. Keep it light: no heavy opening screen, no PDFs, fewer and smaller photographs that load as guests scroll, and a code that opens the menu directly. Test it at the back of the room, on mobile data, on an ordinary phone.

Make it fast to use as well as fast to load: section tabs, search and the three taps rule, text large and clear enough for dim light, and buttons built for the thumb. Plan for guests with a weak signal, keep the menu in step with the kitchen during service, check the booking page and payment page too, and watch how guests use the menu to keep improving it.