01
The menu is content, not a PDF
The menu lives in the editing screen, so a price change takes about a minute on a phone. The download is gone, and with it the reason to avoid updating it.
Ember & Salt
A phone-first restaurant site where the menu is content, not a PDF — change a price and publish in about a minute.
A demo site I designed, built and measured myself. The performance numbers here are real; there is no client behind it.
The problem
Most restaurant sites bolt the menu to the side as a PDF, so every price change becomes an email to a developer and the menu quietly goes out of date.
It also has to work on a phone, at a table, in poor light — because that is where it is actually used, not on a laptop in an office.
What I built
02
Phone-first, because that is where it is read
Designed for a thumb before anything else: tap-to-call above the fold, the menu one scroll away, and no pinch-zoom anywhere on the site.
03
Photos that survive a slow connection
Food photography compressed per screen size and lazy-loaded, so the page still arrives in under a second on a weak signal.
The result
- 98
- PageSpeed at launch
- 0.8s
- full page load
- 1 min
- to change a price
↳ the handover
↳ the screen an owner would use every Sunday
Every site I hand over ends this way: the owner gets this screen, and a short walkthrough on the day it goes live. Tap a field, type, hit publish — the live site updates straight away.