Website speed: the three second rule on 4G

On the office wifi, the restaurant's new website loads in a blink, and everyone agrees it looks wonderful. On a guest's phone, on a busy street, on a patchy mobile signal, the same website shows a white screen for four seconds, then a spinning wheel, then half a photo. The guest has already gone back to their search results. Website speed is invisible to the people who build a website and decisive for the people who use it.

Restaurant websites are visited by hungry people in a hurry, mostly on phones, often outdoors or on the move. They have several other venues one tap away. A page that takes more than a few seconds to show something useful loses many of them before they have seen the menu. The good news is that most of what slows restaurant websites down is easy to find and simple to fix.

This guide covers why speed matters, the three second rule of thumb, how to test a website honestly on a phone, what makes restaurant websites slow and the two fixes worth doing first. Every venue and figure in it is an example.

A restaurant website is often visited at the moment of decision: a guest is choosing between a few places for tonight. If one website shows its menu and booking button at once, and another keeps them waiting, the first usually wins. Speed is part of the guest's first impression, before the food, the photos or the prices.

Speed also matters for the booking itself. A guest who taps "Book a table" and waits for a slow booking page may give up at the last step. Every second between interest and a confirmed booking loses some guests.

A widely quoted rule of thumb is that many visitors leave a page that takes more than about three seconds to show something useful on a phone. The exact number matters less than the principle: people waiting for a page lose patience quickly, and the longer the wait, the more of them leave.

Treat three seconds as a ceiling, not a target. The aim is a page that shows the venue's name, a photo and the booking button almost at once, on an ordinary phone and an ordinary mobile connection, with the rest following quickly.

Mobile connections vary far more than office wifi. A phone may show 4G but get a weak signal indoors, in a basement, on a crowded street or on a train. The connection a guest has while standing outside deciding where to eat is often much slower than the one the website's designer tested on.

That is why testing on wifi is misleading. A website has to work well on the slow, uneven mobile connections real guests use, not just on the fast connection in the office.

Test website speed the way guests experience it. Use an ordinary phone, not the newest model. Turn wifi off, so the phone uses its mobile connection. Open the website in a private window, so nothing is remembered from earlier visits. Then time how long it takes to see the venue's name, a photo and the booking button.

Do it in a few places: in the venue, outside on the street and somewhere the signal is weaker. Then tap through to the menu and the booking page, timing each. That gives you a far more honest picture than any number from the designer's laptop.

Free tools give a more detailed view. Google's PageSpeed Insights measures a page's speed on mobile and desktop and suggests what to fix. Browsers have built-in tools that show what a page loads and how long each part takes. These tools belong to the wider practice of web performance, the work of making websites fast.

Use them alongside the phone test, not instead of it. The tools explain why a page is slow; the phone test tells you what guests feel.

Speed tools often report a few measures that search engines call core web vitals. One measures how long the main content of the page takes to appear. One measures how quickly the page responds when someone taps it. One measures whether the page jumps around as it loads, such as text moving when an image appears.

You do not need to master them. Watch the first most closely, because it is closest to what guests feel: how long until the page shows something useful. And notice if the page jumps, because a booking button that moves just as a guest tries to tap it is a common cause of frustration.

Most restaurant websites are slow for the same few reasons. Photos uploaded at full camera size. A video playing in the background of the home page. Several fonts. Plugins and widgets added over the years, such as an Instagram feed, a review widget, a chat box and a pop-up. Cheap or overloaded hosting. And sometimes a website builder that adds more code than the page needs.

The two biggest causes, by far, are usually images and extra scripts. Fixing those two first often makes more difference than everything else combined.

The first fix is the images. Website photos taken on a modern phone or camera are often several megabytes each, far larger than any screen needs. A home page with a few of them can take many seconds to load on a mobile connection, even though each photo is shown at a fraction of its size.

Resize photos to the size they are shown, compress them and use a modern web format where your website allows. Most website builders and free tools can do this. Then reduce the number: a few good photos load faster, and look better, than a gallery of dozens.

A photo on a phone screen rarely needs to be more than about twice the screen's width in pixels, to look sharp on high-resolution screens. A photo shown across a wide computer screen needs more, but not the full size from the camera.

As a rule, if a single photo on your website is larger than a few hundred kilobytes, it can probably be made smaller without anyone noticing a difference. Load photos further down the page only when the visitor scrolls to them, so the first screen appears quickly.

The second fix is video and extra scripts. A background video on the home page can be the heaviest thing on the website, and on a phone it often plays poorly or not at all. Pop-ups, chat widgets, tracking tools and other add-ons each load their own code, and together they can add seconds to every page.

Remove what you do not need. Replace a background video with a single photo, or offer the video as something to tap. Remove widgets nobody uses. Keep only the tracking tools you actually look at. Every script removed makes the website faster for every visitor.

Widgets that pull in content from other services, such as a live Instagram feed, a review widget, an embedded map or a booking widget, are convenient but can be slow, because each one loads from another company's servers. If one of those servers is slow, your page waits for it.

Use them sparingly. A link to your Instagram profile loads instantly; a live feed may not. A small static map image with a link to directions is lighter than an embedded interactive map. Where a widget is important, such as booking, check that it loads quickly on a phone.

Fonts add weight too. A website using several custom fonts, each in several weights, has to download all of them before the text looks right. On a slow connection, that can delay the page or make text appear in the wrong font and then jump.

Use one or two fonts, in the weights you actually need. Many websites look perfectly good with one custom font for headings and a standard font for body text. The page loads faster, and the text is readable at once.

Where the website is hosted affects its speed. Very cheap hosting, or a server shared with thousands of other websites, can be slow regardless of how well the website is built. Most modern website builders host websites on fast networks, which is one of their advantages.

If your website is slow even after fixing images and scripts, ask whoever looks after it about the hosting. Moving to better hosting, or to a builder with good hosting included, can make a noticeable difference.

Test booking page speed separately. A website can be fast while its booking page, often provided by another service, is slow, or the other way round. Time how long it takes from tapping "Book a table" to seeing available times, on a phone and off wifi.

If the booking page is slow, check whether it is embedded in a heavy page or loading extra code. Sometimes a direct link to the booking page, instead of an embedded one, is faster. The booking route is the last step before a booking, so it deserves the most care.

A mobile website has to be fast on the phones and connections guests actually have. Designs that look impressive on a desktop, with large images, animations and video, are often the slowest on a phone. Designing for the phone first usually produces a lighter, faster website.

Check the mobile website after every change. A new photo, a new widget or a new section can slow it down without anyone noticing on the office computer. Our guide to mobile website first, because that is the traffic covers designing for phones.

Speed is a design decision, not just a technical one. Restaurant website design that puts the menu, the booking button and one good photo on the first screen, without video, pop-ups or heavy effects, is usually fast by nature. Design that leads with spectacle is usually slow.

When choosing between two designs, ask which one shows a hungry guest what they need sooner. Our guide to restaurant website design that gets out of the way covers the design decisions that help.

The menu is the most visited page on most restaurant websites, so its speed matters most after the home page. A menu as a web page, with text and a few photos, loads quickly. A menu as a large PDF can take many seconds on a phone, and some phones open it in a separate app.

Put the menu on a web page, keep photos on it few and small and check its speed on a phone. A guest who can read the menu in seconds is far more likely to go on to book.

Search engines take page experience into account, including how quickly pages load on phones and whether they jump around as they load. A fast website is not guaranteed to rank higher, but a slow one gives search engines and guests a reason to prefer somewhere else.

Speed improvements usually help both: guests stay longer and book more, and search engines see a better experience. The free speed tools show the same measures search engines use, so improving them helps on both fronts.

Measure speed before and after each change, using the same test: the same phone, the same place, wifi off, a private window. Record the time until the page shows something useful and the time until the booking page shows available times.

Small improvements add up. Resizing images might save two seconds; removing a background video might save another. Recording each change shows which fixes made the biggest difference, and keeps the website from slowly getting heavier again.

Websites tend to get slower over time, as photos are added, widgets are installed and sections are bolted on. A website that was fast at launch can be slow two years later without anyone deciding to make it so.

Check speed once a month, as part of the website check: the phone test and a run through a free speed tool. Before adding anything new, ask whether it is worth the extra time it will add to every visit.

Sometimes a website is so heavy, or built on such old foundations, that fixing it piece by piece is not worth it. If the website is still slow after fixing images, scripts and hosting, a rebuild on a lighter, modern platform may be the better choice.

If you rebuild, set speed as a requirement from the start: the first screen visible within a couple of seconds on a phone, the menu as a web page and the booking button one tap away. It is far easier to build a fast website than to make a slow one fast.

To keep a restaurant website fast, check:

Guests do not always arrive on the home page. Many land on the menu page from a search, on the booking page from a social profile or on a blog post from a link. Each of those pages needs to be fast too, because for that guest it is the first impression.

Test the pages guests most often land on, not just the home page: the menu, the booking page, the find-us page. A fast home page is little comfort to a guest whose first page took eight seconds.

Heavy pages cost guests more than time. On a mobile plan, every large photo and video uses some of the guest's data allowance, and some guests, especially visitors from abroad, are on expensive or limited plans. A website that loads several megabytes before showing the menu is unwelcome to them.

Light pages are considerate as well as fast. A menu page that shows text and a few small photos respects guests who are watching their data, and they are more likely to stay on it.

Websites often change hands: a new manager, a new designer, a new agency. Each new person adds their own tools, plugins and tracking, and speed suffers. When someone new takes over the website, ask them to check its speed before and after their changes.

Agree a simple rule for anyone working on the website: nothing goes live that makes the home page or the booking route noticeably slower on a phone.

An invented bistro's new website loads quickly in the office but takes over six seconds to show anything on a phone outside the venue. A free speed tool shows why: a background video on the home page, eight photos uploaded at full camera size, a live Instagram feed and a chat widget nobody uses.

The bistro replaces the video with one photo, resizes and compresses the images, swaps the Instagram feed for a link and removes the chat widget. The home page now shows the name, a photo and the booking button in under two seconds on the same phone, the menu page is faster still and more of the visitors who tap "Book a table" go on to finish the booking.

servearound does not host the venue's own website, so the speed of its pages is down to how the site is built. The booking page and the menu page servearound provides are ordinary web pages on servearound.com, not PDFs, and the booking page can be linked from the website or embedded on it as a widget, so a slow website does not have to mean a slow route to a table: a direct link to the booking page skips the website altogether.

Test both routes the way this guide describes, on a phone and off wifi: the website, and the booking page on its own. Reservation analytics show bookings from the booking page and from the embedded widget as separate sources, so you can see which route guests use. See the reservations module and Campaigns.

Fast enough to show the name, a photo and the booking button within about three seconds on a phone.

On an ordinary phone, with wifi off, in a private window, timing how long the page takes to show something useful.

Large photos and extra scripts, such as background video, pop-ups and widgets.

Resize and compress the images, and remove video and scripts you do not need.

Often, yes, because each loads code from another service. Use links where you can.

Search engines take page experience into account, so a fast website helps.

Yes. Time how long it takes to show available times on a phone.

Monthly, and after any change to the website.

Website speed decides whether a hungry guest on a phone sees your menu or goes elsewhere. Aim to show the venue's name, a photo and the booking button within about three seconds on an ordinary phone and an ordinary mobile connection, and test it honestly: wifi off, a private window, outside on the street.

The two fixes worth doing first are the images, resized, compressed and fewer, and the extra scripts, removing background video, pop-ups and widgets nobody needs. Then check fonts, hosting, the menu page and the booking page speed on its own. Measure before and after each change, check monthly and treat speed as part of restaurant website design rather than an afterthought.