A restaurant added its menu as a PDF to the website, scanned from a printed copy. It was an image of text, forty megabytes, and not searchable.
On a phone, it took a long time to download and then had to be pinched and dragged around. Many customers gave up. Search engines could not read it, so dishes never appeared in results.
The owner replaced the file with ordinary text on a page, with a small printable version, and the page loaded in a fraction of a second. The restaurant is invented, but the story is one of the most repeated in small-business web work, and almost everyone who has run a café, a pub or a takeaway has either done it or seen it.
How the menu got there
The restaurant was a family-run place with about thirty dishes, a short wine list and a children's menu. The printed menu was a handsome thing, designed years earlier by a local graphic artist and run off on thick cream paper. When the owner's daughter set up the website, she did what seemed obvious: put the printed menu on a scanner, saved the result as a PDF, and uploaded it. A button on the home page said "View our menu".
It took ten minutes, it looked exactly like the real menu, and it matched what was on the tables. Nobody thought any more about it for a year.
The trouble is that a scan is a photograph. The PDF contained no letters at all, only a large picture of letters. To a human on a big screen it is a menu. To everything else it is a grid of coloured dots.
What customers saw on a phone
Most people who look at a restaurant's menu are standing in a street, or on a bus, with a phone and a mobile connection of variable quality. They tap the button, and the browser begins to fetch a 40 MB file.
| Connection (example speed) | Time to fetch 40 MB |
|---|---|
| Good 4G or 5G, 40 Mbit/s | about 8 seconds |
| Ordinary mobile signal, 10 Mbit/s | about 32 seconds |
| Weak signal, 3 Mbit/s | about 1 minute 45 seconds |
These are the best cases and ignore connection setup and dropouts. Meanwhile many phone browsers do not show a PDF as a normal page. They hand it to a viewer, which shows a blank sheet until enough has arrived. When it does appear, the page is the size of a menu on a table: A4 shrunk onto a five-inch screen. The text is tiny, so people pinch to zoom, then drag sideways to read each line, then pinch out to find their place. Prices end up on the far right of a wide page, next to a dish name now off the left edge of the screen.
The restaurant had no way to measure the people who gave up, but its own staff noticed that callers were increasingly asking, "Do you do anything vegetarian?" about dishes that were on the menu.
What search engines and screen readers saw
A search engine builds its index from text. A scanned PDF has none, so any engine that does not run character recognition on it has nothing to index. Some do try, and the results are patchy: a stylised font, a decorative border or a photo of a table with a shadow across it can produce nonsense or nothing. The practical outcome is that someone searching for a specific dish, or "vegan brunch near the station", would never see the restaurant's menu come up. The listing might appear, but not the thing that answered the question.
Screen readers have the same problem. A blind customer using one hears "image" or silence, and cannot read the dishes, the prices or the allergen notes. A text page works with these tools by default.
You can test whether a PDF contains text without any special software on a computer where the poppler tools are installed:
$ pdftotext menu.pdf - | head
(no output)
$ pdffonts menu.pdf
name type encoding emb sub uni object ID
------------------- ----- --------- --- --- --- ---------
(no fonts listed)
$ ls -lh menu.pdf
-rw-r--r-- 1 user user 40M menu.pdfNo text and no fonts, in a file that large, means it is a picture. Trying to select a word with the mouse in a PDF viewer tells you the same thing.
The rebuild
The owner's daughter wrote the menu out as headings and short paragraphs on a page of its own. Starters, mains, sides, puddings, drinks. Each dish had a name, a line of description and a price. The page used plain HTML headings and lists, so it scaled to any screen, and the text could be enlarged by the visitor's own settings.
<h2 id="mains">Mains</h2>
<ul class="menu">
<li><strong>Fish pie</strong> Smoked haddock, prawns, mash crust. <span class="price">£14.50</span></li>
<li><strong>Mushroom risotto</strong> (v) Wild mushrooms, parsley. <span class="price">£12.00</span></li>
</ul>Dietary and allergen notes went next to each dish, in words, with a line at the bottom of the page telling guests to ask staff about anything not listed. Rules about allergen information differ by country, and keeping the page accurate is the restaurant's responsibility, so she checked the current guidance for her area rather than relying on the old printed design.
A few extras made the page behave. A short list of anchor links at the top (Starters, Mains, Puddings, Drinks) lets a phone user jump straight to a section. Prices sit in a consistent place at the end of each line. A simple print stylesheet hides the navigation so that anyone who wants paper gets a clean sheet:
@media print {
header, nav, footer, .cookie-banner { display: none; }
body { font-size: 11pt; color: #000; background: #fff; }
}The printable version
Some guests like paper, and some local newsletters want a menu to reproduce. The restaurant kept a PDF, but a different kind. It was exported from the original design software and from the text, not scanned, at a modest size of about 180 KB, with real fonts embedded and the text selectable. A link on the menu page says "Printable menu (PDF)" and states the size, so nobody is surprised.
The old 40 MB scan was deleted from the server. It had also been taking up a good share of the account's disk space and ran through every backup. If you do keep a scanned original for the archive, store it somewhere other than the public website.
Results, and what is still imperfect
The menu page weighs around 25 KB of text, with a couple of small images. On the same weak connection that took nearly two minutes to fetch the PDF it appears within a second. Within a few weeks the restaurant showed up in searches for individual dishes. It has not become a rival to the review sites, and no one should expect it to; what changed was that the website finally answered the question visitors came with.
One thing remained imperfect: the designer's typography. The text page is plainer than the printed card. The owner decided she would rather be readable than beautiful on a phone, and added the printed design as a header image, compressed to well under 100 KB.
Checking it yourself
Open your own menu link on your phone, with Wi-Fi turned off, and count seconds. Then try to select a word. Then check the file size from a terminal:
curl -sI https://example.com/menu.pdf | grep -iE "content-length|content-type"Anything over a couple of megabytes is a candidate for a rebuild. The page weight tool will give you the numbers for a page, and the troubleshooting guide covers slow pages in general.
What stayed with them
A menu is information people want in a hurry, on a small screen. Put it on the page as text, keep any PDF small and real, and test it with your own phone on a poor connection. If a file you publish cannot be selected, searched or read aloud, it is a picture, and your visitors are being asked to put up with it.