Slow Portfolio Photos? Check the Delivered Image Before Re-exporting

A portfolio feels slow on your phone, so you export the whole gallery at a lower JPEG quality. The files get smaller, but the opening photograph still appears late. Before sacrificing more detail, find out which image the browser actually receives and when it starts requesting it. An oversized upload, a wrong responsive variant and a late-loading gallery can produce the same frustrating blank space.

Use one public gallery for this check. Keep the original photographs and export preset intact until you can name the bottleneck. Your web gallery, client download and print master serve different purposes; they should not share one destructive size limit.

Follow one photograph from upload to screen

There are three sizes to distinguish: the file you upload, the derivative your platform delivers, and the space the photograph occupies on the page. A 6,000-pixel upload does not prove that every visitor downloads 6,000 pixels. Equally, a small thumbnail on screen does not prove that its downloaded file is small.

Start with the opening photograph, then repeat for one gallery thumbnail and the enlarged lightbox view. These can use different delivery paths. If the site generates its own variants, changing the upload quality may simply add another lossy compression step without correcting which variant is selected.

1. Open the published gallery in Chrome and open DevTools. In Network, select the image filter, enable Disable cache and reload while DevTools remains open. Record the viewport and device pixel ratio used for the test.
2. Inspect the photograph in Elements. For an image element, its currentSrc property identifies the source the browser selected; the literal src attribute may only be a fallback. Match that URL to its Network request. For a CSS background, inspect the computed background image instead.
3. Record the delivered file's pixel dimensions, response content type, transferred bytes and request timing. Use the actual returned file for dimensions rather than trusting a width parameter in its URL. Record the rendered width separately.
4. Reload at a narrow mobile viewport in a fresh test, rather than only shrinking a desktop window after the large image has loaded. Then open the lightbox and check whether a larger image is requested only when needed.

Disable cache controls the browser cache for this debugging session; it does not flush the image CDN. If a request is served by a service worker, note that too. Compare tests using the same network throttling and cache conditions so a warm repeat visit is not mistaken for a better export.

Match the repair to what arrived

The phone receives a much larger image than its display needs

Check responsive delivery first. With width-based srcset, the page offers image candidates and sizes describes the expected display slot. The browser uses these hints along with device conditions to choose a resource. MDN's responsive-image guide explains how this differs from simply shrinking an image with CSS.

For a teaching example, a photograph displayed 360 CSS pixels wide on a 2× screen has roughly 720 device pixels across that slot. That is a useful starting point for comparing candidates, not a rule that the browser must fetch an exactly 720-pixel file. Available variants, zoom, cropping and browser decisions matter. If that view repeatedly fetches the 4,000-pixel original, inspect the candidate list and slot hint before lowering every image's quality.

A full-width cover and a three-column gallery tile should not necessarily advertise the same slot size. If your platform owns this markup, send support the page URL, viewport, selected image URL and measured dimensions. That gives them something more actionable than “the photos are too big.”

The dimensions are sensible, but the delivered file is still heavy

Now an export or encoding comparison is worthwhile. Choose photographs that stress different details: hair or foliage, a smooth sky, and skin or shadow gradients. Compare the current derivative with alternatives at the same dimensions and crop. Inspect at the intended display size, then zoom in to locate artifacts; do not select a setting solely because a percentage slider looks familiar.

Watch for smeared texture, ringing around sharp edges and banding in smooth tones. If a smaller candidate preserves the details that matter in the portfolio, test it in the published page. If the platform re-encodes uploads, judge the final derivative rather than only the local export. Keep color handling consistent during the comparison so a profile change is not confused with compression damage.

JPEG, WebP and AVIF are candidates to evaluate against your actual photographs and delivery support. A quality value of 80 in one encoder is not a promise of the same appearance in another. Nor is there a universal kilobyte ceiling that fits a tiny tile, a panoramic cover and a full-screen detail view. Set separate budgets for those roles and check the total gallery cost.

For example, 24 files at 250 KB each total 6,000 KB of image payload before other resources. This is arithmetic, not a measured gallery result. Even a reasonable-looking per-image size can become expensive if all 24 are requested immediately. Loading offscreen work as it becomes relevant can matter more than shaving a little quality from every photograph.

The image is small, but the request starts late

Use a Performance recording to identify the actual Largest Contentful Paint element. It may be your opening photograph, but it can also be text. For an image LCP, distinguish waiting for the document, waiting to start the image request, transferring the image, and waiting to render it.

Google's LCP optimization guide makes this breakdown explicit. Compressing a photograph mainly addresses transfer time. It cannot by itself fix a gallery that waits for JavaScript before exposing the image URL, or keeps an already downloaded image hidden behind an entrance effect.

Check whether the LCP image is mistakenly lazy-loaded and whether its URL is available in the initial HTML. Give the actual opening image appropriate priority when testing shows a benefit; do not mark every gallery photo high priority. Images below the initial view can still load lazily. A CSS-background cover may need a different discovery fix from an ordinary image element, so give the developer the waterfall and element rather than prescribing a blanket plugin setting.

Accept one gallery before changing the library

Save a before-and-after record with the same page, viewport, network profile and cache state. Include the selected image URL, dimensions, bytes, request start and LCP. Repeat the measurement to distinguish a consistent change from one unusually fast request. Then look at the actual gallery on desktop and phone: faces, texture, cover crop, lightbox detail and the route to an inquiry should still work.

A faster first photograph is only part of the experience. Scroll through the gallery and open several images. Check for layout movement, delayed controls or a lightbox that downloads the full library at once. Guangsuan's guide to LCP, INP and CLS explains the broader loading, interaction and stability checks once the image-delivery problem is understood.

Keep lab measurements separate from real-user results. PageSpeed Insights may show URL-level field data, origin-level data or no field data when traffic is insufficient. Check which one you are reading. A single improved score is useful diagnostic evidence, not proof that every visitor now has the same experience or that search rankings will rise.

When discussing a gallery implementation, use the PhotoWebs feature overview to identify the relevant gallery or image-processing workflow, then attach your measured example. Approve the change on that gallery before applying it across the library. The useful outcome is a clear decision: resize the derivative, correct its selection, change its encoding, or make it arrive earlier.