A 2400-pixel photograph displayed in a 600-pixel column should not automatically be delivered at its original size. The browser would transfer and decode pixels only to scale them down. On a research archive, that mismatch might affect a conference photograph, a scanned page, or a figure from an early computer-vision paper. The aim is to match the file to its place on the page while keeping the details readers need.
Why images affect more than download time
Images are often among a page's largest files. On a slow connection, a large image takes time to transfer; the browser then has to decode it and place it in the layout. If an image near the top arrives late, the main visible content may appear late too. Several large images loading together can compete with other resources.
Bytes are only part of the problem. An image with no space reserved for it can push text down when it appears. A small thumbnail might load quickly but leave a document label or plotted axis unreadable. In a historical-technical archive, a figure is often evidence rather than decoration, so speed and legibility need to be judged together.
Deliver only the pixels a layout can use
Start with the rendered width, not the camera or scanner's original dimensions. For a figure displayed at 600 CSS pixels across, a 600-pixel source may be enough on a standard-density screen. A roughly 1200-pixel variant can look sharper on a high-density display, but not every visitor needs that larger file. Responsive variants let the browser select a source suited to the layout and display.
Check mobile layouts too. An image may fill a narrow viewport while still appearing much smaller than the desktop original. Provide several generated sizes and accurate srcset and sizes information so a small screen does not receive an unnecessarily large asset. The sizes value needs to reflect the actual layout; if it overstates the displayed width, the browser may choose a larger file than it needs.
Cropping calls for a separate judgment. A wide archival photograph might make a useful card thumbnail, but cropping a plotted result could cut off its legend. Use smaller previews in post lists while keeping an uncropped version available when context matters. Check multi-panel figures on mobile rather than assuming that shrinking them leaves every panel readable.
Choose a format for the material
- Photographs: JPEG remains widely usable. WebP and AVIF can often produce smaller files at comparable visual quality, but compare the outputs rather than assuming one format always wins.
- Diagrams and interface captures: Test PNG, WebP, or AVIF when text and hard edges matter. Aggressive lossy compression can blur small labels.
- Simple icons and line drawings: SVG stays crisp at different sizes when the artwork is genuinely vector-based. Converting a photographic scan to SVG offers no such advantage.
Judge compression quality alongside file size. Saving bytes is a poor trade if it obscures a phonetic annotation, a medical-image boundary, or a faint line in a stereo-reconstruction diagram. Keep the original as an archival master and make separate web versions. That way, you can generate new versions if formats or display needs change.
Load images when they are needed
Images well below the first screen can usually be lazy-loaded, so their transfer waits until a reader approaches them. That helps on a long proceedings index or an illustrated technical history post. A prominent image near the top needs different treatment: lazy-loading it may delay the content the visitor came to see.
Tell the browser how much space each image will occupy. Width and height attributes, or an equivalent aspect ratio, let it reserve space before the file arrives; responsive CSS can still scale the image for a smaller screen. For a scanned figure with a caption, that keeps the caption and following paragraph from jumping as the image loads.
These choices address one part of archive performance: delivering images at a useful size and time without shifting the surrounding page. The post on making a research archive faster without losing what matters looks at the wider balance.
Check the page, not just the exported file
An export tool can show a substantial size reduction while the published page still requests the oversized original. Inspect image requests in a browser at desktop and mobile widths. Compare transferred bytes, intrinsic dimensions, and rendered dimensions, and check that thumbnails use smaller versions rather than full-resolution scans. The same image may need different files for a post listing and the article itself.
Use representative material for visual checks, not just an attractive photograph. Test a grayscale document, a chart with thin lines, and an image with small text. View each at its published size and, if readers are offered a closer look, at that enlarged size. A quality setting that suits a conference-room photograph may damage a scanned table.
Compare page behavior before and after under similar conditions. Browser performance tools can show whether the largest visible image loads sooner and whether layout shifts have decreased. Network throttling can reveal delays hidden by a fast local connection. Repeat the test: caching and network conditions make a single timing result unreliable.
Accessibility and historical fidelity set useful limits. Descriptive alt text explains an image's purpose to readers who cannot see it, but it does not replace a legible scan or a transcription where one is needed. Compression must not erase marginal notes, publication marks, or other clues to provenance. If the smallest variant loses an essential axis label, use a clearer preview and keep a larger version available.
For a first pass, inspect the largest image in the first screen of a representative article. If its intrinsic width is several times its rendered width, generate a smaller version and check which file the browser actually requests on mobile. Before replacing the published image, compare the plotted labels at the size readers will see.