Start with the images a guest sees first, then look for large images downloaded before they are needed. A full-width menu banner or an oversized first-row food photo can be a better first fix than a tiny thumbnail near the bottom. Keep useful pictures, but ask your website provider to deliver appropriately sized files and delay images that appear farther down the page.
The goal is not simply to make the image files smaller. Guests need to recognize dishes, read prices and reach the order button without waiting for a page crowded with downloads. Use one representative mobile menu page to decide what to change first, then compare the result under the same conditions.
Measure a menu page guests actually use
Choose a page that combines important menu content with several images: for example, the main ordering menu on your restaurant website. If your dine-in menu and online ordering menu use different pages, pick the one where slow loading is most likely to interrupt a guest’s next step. Check the other page later rather than assuming both behave alike.
Open the page on a phone using a normal mobile connection. Note what appears first, when the menu becomes readable and whether the order or category controls respond. Scroll through the page and watch for blank spaces, images popping in late or content shifting under your finger. Repeat the visit a few times; a single slow connection or a phone doing other work can distort the result.
Ask the person who manages the site to collect the technical details using browser developer tools or a page-speed tool. They should record the page address, device or test profile, connection conditions and test date. For each prominent image, request its displayed dimensions, the dimensions of the file sent to the phone, its download size and when it begins loading. Also ask for the total image download size for the page and which images load before a guest scrolls.
File size is the amount downloaded, usually shown in kilobytes or megabytes. Pixel dimensions describe the image’s width and height. Both matter: a photo can have far more pixels than its display needs, while compression can affect download size without changing those dimensions. Record the initial results before editing anything so you have a baseline.
Find the images worth fixing first
Sort images by their role, their download size and when they load. Give early attention to a large banner or first-row dish photo if it takes substantial bandwidth and appears as soon as the menu opens. Then look for images below the first screen that download immediately even though the guest may never reach them. A large offscreen gallery can compete with the menu content the guest came to use.
Check whether the phone receives a much larger file than the space shown on screen requires. A desktop-sized photo squeezed into a small mobile card may look fine, but the browser still has to download the supplied file. Ask the site manager whether the page sends a smaller version to mobile devices or only shrinks the display.
Next, question whether every image earns its place. A clear photo of a signature dish may help someone choose. Several near-identical photos of the same item, a decorative background behind a menu, or images for every minor add-on may not. Remove or simplify a photo only after considering what information it gives the guest. Names, descriptions, prices and ordering controls should remain easy to find.
Don’t assume images are the only cause of a slow page. If the menu text and controls also wait on other requests, ask the provider to investigate those separately. The image audit gives you a focused starting point, not proof that changing photos will fix every delay.
Choose image sizes and loading behavior
Ask for image versions suited to the spaces where they appear. A wide banner and a small dish thumbnail have different needs; using the same large source file for both can waste bandwidth. A responsive setup can give the browser a choice of image sizes so it can select an appropriate file for the device and display. Check the result on a sharp phone screen as well as a larger screen before approving it.
Compression reduces file size, but too much can make food look muddy or add visible artifacts. Ask for a visual comparison at the actual display size. Consider a modern image format when the site supports it, while making sure guests’ browsers can still display the menu images. The best setting is the smallest practical file that keeps the dish recognizable and appetizing, not simply the smallest possible file.
For images below the first screen, ask whether they can load as the guest approaches them. This is often called lazy loading. It can reduce the amount downloaded at the start, but applying it to the main visible image may delay that image instead. The page should also reserve space for images so late arrivals do not push prices or buttons around. Check that a guest who scrolls quickly does not reach a menu full of blank cards.
Hypothetical example: A menu initially downloads a 1,200 KB banner, four 300 KB first-row photos and six 250 KB photos farther down the page. Those images total 3,900 KB. The owner keeps the banner and all ten dish photos, but asks for smaller versions and delayed loading for the six lower photos. The revised banner is 400 KB and each first-row photo is 120 KB, so those five images total 880 KB, a reduction of 1,520 KB from their original 2,400 KB.
If each lower photo is also reduced to 100 KB, all eleven revised images total 1,480 KB when loaded, compared with 3,900 KB originally. Delaying the six lower images changes when their 600 KB is downloaded; it does not make that download disappear if the guest scrolls to them. These figures are assumptions for prioritizing a test, not a prediction of a page’s load time. They cover image downloads only, not scripts, fonts, other page files or the cost of making the changes.
Use the worksheet and compare the result
Use the worksheet below for a first pass. Its entries are illustrative; replace them with measurements from your own menu. The priority column tells the person doing the work which issue to investigate first, while the check column makes the change observable to the owner.
| Image or group | What to record | Priority action | Check after change |
|---|---|---|---|
| Top menu banner | Download size, displayed size and when it appears | Resize and compress if oversized; keep it available early | Banner appears clearly without holding up menu use |
| First-row dish photos | File dimensions and total download size | Serve versions suited to mobile cards | Dishes remain recognizable; names and prices stay readable |
| Lower menu photos | Number and size loaded before scrolling | Reduce files and consider delayed loading | Photos appear as the guest scrolls; layout stays stable |
| Decorative or duplicate images | Purpose and download size | Remove or simplify where they add little | The page still explains the menu and supports ordering |
After changes, revisit the same page on the same phone and connection where practical. Use the same test settings and note whether the browser is loading a fresh copy or using files saved from an earlier visit. Compare the initial image download total, the largest visible files and the point at which the menu becomes usable. Repeat each check and look for a consistent pattern rather than treating a single result as conclusive.
Then perform a simple guest journey: open the menu, find a dish, read its details and reach the ordering control. This is a browsing check, not a live order; do not submit a payment or send an order. Check both a quick scroll and a slower browse. If photos look worse, important content shifts, or ordering controls become harder to use, ask for an adjustment even if the download total fell.
Agree on who owns future image uploads. Give staff a simple size and quality guideline, and ask whether the website automatically creates appropriate versions or requires a manual step. When comparing providers, include image controls and mobile checks alongside the questions in this restaurant website builder comparison. Ask for the work involved and a written quote before approving changes.
Use the worksheet on your current menu, then ask Fleksa about its restaurant website, image setup options and verified availability for your US location.
Frequently asked questions
Should I remove all photos from my menu?
No. Keep photos that help guests choose, especially for distinctive dishes. First reduce oversized files and reconsider duplicates or decorative images that add little useful information.
Should every menu image load only when someone scrolls to it?
Not necessarily. Delaying images below the first screen can reduce initial downloads, but delaying a prominent image already on screen may make it appear later. Check the actual guest experience.
How do I know whether an image change helped?
Compare the same page on the same device and connection, using consistent test settings. Look at image download sizes and timing, then check whether the menu is readable, stable and easy to use.
