Key facts
- The home page returned six kilobytes and a perfect Lighthouse mobile score with a largest contentful paint under one second.
- The gallery page returned 7,439,734 bytes, because eight JPEG photos were embedded directly in the HTML as base64-encoded text rather than linked as image files.
- No image tag existed anywhere else on the site, so the gallery was the only visual proof of the shop's work and the only heavy page.
- Base64 images cannot be cached separately, resized for phones, lazy-loaded below the fold or indexed by image search, so the shop paid every cost of the photos and received none of the benefits.
- The fix served the photos as compressed image files in two sizes with lazy loading, which brought the page to a fraction of its weight without removing a single picture.
The finding
The shop's site was nine hand-coded pages, and eight of them were tiny. The ninth, the gallery, was a single HTML file of more than seven megabytes. Opening it showed eight photographs of tinted cars; opening the source showed each photograph pasted into the page as a long run of base64 text. On a phone over a mobile connection, the page a customer opens to judge the work took long enough to load that many would not wait.
What we looked at
We fetched each page and recorded its size in bytes. We ran Lighthouse on mobile for the home page and the gallery. We searched the site's HTML for image tags and found none outside the gallery, and inside the gallery we found data URIs rather than file paths. We checked whether any smaller versions of the photos existed on the server for phones; none did, because there were no image files at all.
Why it mattered for leads
A tint customer decides on the finish: clean edges, no bubbles, the right shade on a car like theirs. The gallery is where that decision happens, and a seven-megabyte page on a phone in a parking lot is a page that never finishes loading. Beyond the wait, images pasted into HTML cannot be cached, so every visit downloads everything again; they cannot be resized, so the phone gets the full-size file; they cannot be lazy-loaded, so all eight arrive before the first is shown; and they never appear in image search, where car owners look for examples of a shade.
False positive checks we ran
We checked whether the gallery was an unlinked page nobody reached; it was in the main navigation. We checked whether a content delivery network or compression was shrinking the transfer in practice; the transferred size matched the file size. We checked whether the photos were deliberately embedded to prevent copying, which some owners do; they were as easy to save as any image, since the browser renders them normally. We confirmed the rest of the site was as fast as it looked, so the finding was specific to this page.
The fix
The proposal's demo served the same photos as compressed image files in two sizes, with the page loading the small version on phones and the large one on desktops, and with photos below the first screen loading only when scrolled into view. Each image carried an alt description of the car and the shade. The gallery kept the shop's fast, simple feel and dropped to a small fraction of its weight, and the photos became visible to image search for the first time.
How to check your own site for this
Open your gallery or portfolio page and check its total size in your browser's developer tools or with a free page speed test; anything over a couple of megabytes on a page of a dozen photos deserves a look. View the page source and search for the text data:image; if your photos appear as long runs of letters and numbers instead of file names ending in .jpg or .webp, they are embedded. Ask whoever built the site to serve them as files in two sizes with lazy loading.
Related questions
A photo converted into a long string of text and pasted directly into the page's HTML instead of being saved as a separate file. The browser can display it, but it cannot cache, resize, lazy-load or index it the way it does a normal image file.
On a gallery viewed from a phone, yes. A customer in a parking lot on a mobile connection waits for the whole page before seeing the first photo, and many leave. Served as files, the same photos load progressively and are cached for the next visit.
No. All eight photos stayed. They were converted to compressed files in two sizes, loaded lazily, and given descriptions, which made the page lighter and the photos searchable.
Car owners search for examples of a shade on a car like theirs. Photos served as files with descriptions can appear in those results; photos embedded as text never do.
It is rarer, but some page builders and copy-paste workflows embed images the same way. The check is the same: look at the page size and search the source for data:image.
an anonymized finding from a real proposal audit; the business is described by type only; SearchPod sells the services that fix findings like this.
Want your site audited the same way?
Get a free, no-obligation proposal within one business day. We look at your site and your market and tell you plainly what we would do, and what we would not.
Get your free proposal