Mobile performance for photographers’ portfolios

You edited your portfolio on a 27-inch display over a fast connection, and it looks stunning. Your clients are looking at it on a phone, over hotel wifi, the night before the wedding, while three other tabs are open. The gap between those two experiences is where portfolios lose people — a gallery that is gorgeous on desktop and sluggish on a mid-range phone is a gallery most of your visitors experience as slow.

Here is how to make a photography portfolio fast where it actually gets viewed. It applies the Core Web Vitals playbook to the mobile case specifically, and pairs with the portfolio thinking in the portfolio gallery problem.

The mobile reality

Most portfolio traffic is mobile, and mobile means slower, more variable connections and less powerful devices than the machine you edit on. A visitor on a flagship phone on home wifi has a fine time; a visitor on a three-year-old phone on patchy data does not, and that second visitor is closer to your median than you think. Designing for the phone on the slow connection is designing for the realistic case, not the worst case.

Responsive images: the srcset + sizes pairing

The single biggest mobile win is not shipping a desktop-sized image to a phone. The srcset attribute offers the browser several sizes; the sizes attribute tells it how wide the image will display so it can pick the right one. Without sizes, the browser assumes full viewport width and over-downloads. Together, they can mean a phone fetches a 480-pixel image where the desktop gets an 800-pixel one — a large saving on every image, multiplied across a portfolio.

The mobile LCP

On a phone, the Largest Contentful Paint element is usually the first big portfolio image. The same rule applies as everywhere: do not lazy-load it, give it high priority, serve it in a modern format at mobile size. The difference on mobile is that the penalty for getting it wrong is bigger, because the connection is slower — a too-large hero that is merely sluggish on desktop can be genuinely painful on data.

Touch performance and the lightbox

When a visitor taps a thumbnail to open it, the delay before the lightbox responds is INP — and on mobile, sluggish taps feel worse than slow loads because they break the sense of direct manipulation. A heavy lightbox that stutters on tap reads as a cheap site, however good the photos are. A lightweight lightbox that opens instantly reads as considered. This is worth testing by actually tapping through your gallery on a real phone, not just resizing your desktop browser.

The honest device test most people skip

Here is the test that separates a portfolio that is fast for you from one that is fast for clients, and almost nobody does it properly. Take your actual phone — not your newest device, ideally a two- or three-year-old one closer to what your clients carry — turn off wifi so it uses mobile data, and open your portfolio cold (clear the browser cache or use a private window so nothing is pre-loaded). Now time it honestly with the stopwatch in your head: how many seconds until the first image is sharp and not a blur? How long until you can scroll without images still popping in and shoving the layout? Tap a photo — does the lightbox open instantly, or is there a beat of lag?

That cold-cache, mobile-data, older-device run is the experience a real client has when they open your link for the first time, on the train, the evening you send it. It is almost always slower than the warm, wifi, latest-phone experience you have been quietly testing against. If it feels sluggish, that is your honest baseline — and the fixes in this guide are what move it. The point of testing this way is not to feel bad; it is to stop optimising for an experience none of your clients actually have.

Touch targets and the fat-finger problem

One mobile-specific detail that is not strictly speed but ruins the experience anyway: touch-target size. Gallery thumbnails, the lightbox close button, and the next/previous arrows all have to be big enough to tap reliably with a thumb. A close button that is a tiny X in the corner, sized for a mouse cursor, is a daily frustration on a phone — the visitor mis-taps, the wrong image opens, they get annoyed. The accessibility guidelines put the minimum comfortable target at around 24 by 24 pixels, and bigger is better for primary controls. When you do the device test above, deliberately try to close the lightbox and navigate with your thumb; if you fumble it, your visitors will too. A gallery built mobile-first sizes these controls for fingers, not cursors.

Format and delivery on mobile

The format and CDN wins compound on mobile because the connection is the bottleneck. A WebP or AVIF image at mobile size, delivered from a nearby edge node, can be a fraction of the weight of a full-size JPEG served from a distant origin. Each optimisation matters more on a slow connection than a fast one, which is exactly why mobile is where they pay off most. See WebP and CDN strategy for the how.

The mobile portfolio checklist

• Responsive srcset + sizes so phones get phone-sized images.
• First portfolio image eager-loaded, high priority, modern format.
• Lightweight lightbox that opens instantly on tap.
• Dimensions set so the layout does not jump as images load.
• Tested on a real mid-range phone on mobile data, not a resized desktop window.

For a photographer, the reassuring part is that these are gallery-plugin defaults rather than per-image work. FotoGrids generates the responsive sizes, sets dimensions, lazy-loads the right images, and ships a light lightbox in its free tier — so the mobile experience is handled at the gallery level while you focus on the photographs.