An image can look small on a phone while still downloading a large desktop file. Responsive styling controls how the image is displayed, but efficient delivery also requires choosing an appropriate source, reserving space, and loading it at the right time. These decisions affect the visitor’s bandwidth and the time before the important content becomes visible.
This guide develops an image-delivery plan for a fictional course landing page with a hero photograph and several project examples. It focuses on decisions a web designer can document and test. The objective is not to compress every file blindly, but to preserve useful detail while avoiding unnecessary downloads and unexpected movement in the layout.
Separate display size from file size
Display size is the space an image occupies in the layout. Intrinsic dimensions are the pixel dimensions of the underlying file. Download size is the number of bytes transferred. These are related but different. A photograph can be displayed at 400 CSS pixels wide while its source contains several thousand pixels and weighs far more than necessary.
Record all three values during an audit. For the fictional page, measure the hero’s rendered width at representative narrow and wide viewports, then inspect the source dimensions and network transfer. This establishes whether the problem is an oversized file, an inappropriate format, repeated downloads, or something else.
Choose the crop before generating variants
A desktop composition may not communicate well on mobile. A wide photograph can leave the important subject tiny when reduced. Decide whether the narrow layout needs a different crop, rather than merely a smaller copy. This is an editorial decision as well as a technical one: the image should still explain or support the surrounding content.
Keep a master file and record the intended focal point. Generate variants from that source rather than repeatedly recompressing an already reduced image. Use descriptive asset names so editors can distinguish the mobile crop from a resolution variant. A clear asset workflow prevents later uploads from undoing earlier optimisation.
Offer suitable resolution candidates
HTML supports image candidates that let the browser choose an appropriate resource. With width descriptors, the sizes information describes the expected display slot. That description should agree with the real CSS layout. Incorrect slot information can lead to a larger download than needed or insufficient detail on a high-density screen.
MDN’s responsive images guide explains resolution switching and art direction. For a project handover, include the candidate widths and the layout conditions they support. Do not assume that adding several files automatically produces efficient selection; inspect the resource actually downloaded at the chosen viewport.
Reserve space before the image arrives
Include appropriate dimensions or an equivalent aspect-ratio arrangement so the layout can reserve space. Without a known shape, content below the image may move when it loads. That movement is particularly disruptive near buttons, form fields, or text a visitor is already reading.
Responsive CSS can still allow an image to scale with its container. The dimensions communicate its ratio; they need not force an inflexible desktop width on a phone. Check that the CSS preserves the intended ratio and that a mobile crop uses the correct dimensions for its own source rather than copying unrelated values.
Prioritise the important image
An above-the-fold image that forms the main visual content should be discoverable early. Do not apply lazy loading to every image as a universal rule. Delaying a primary image can postpone the content a visitor came to see. Determine which image is actually important in the rendered page before changing its loading behaviour.
Images farther down the page are better candidates for deferred loading. Native browser loading hints can reduce initial work, depending on browser thresholds and the viewport. Treat them as hints and verify actual requests. An image immediately below the fold may still be fetched early, which is not necessarily a defect.
Select formats by content
Photographs, logos, screenshots, and diagrams have different needs. A compressed photograph may tolerate some loss of detail, while a screenshot with small text can become unreadable. Compare candidate formats at the display sizes that matter. File size is only one acceptance criterion; legibility and visual accuracy also count.
Avoid converting a simple vector logo into a large raster image merely to standardise extensions. Conversely, do not assume every vector asset is small or efficient: complex exported artwork can contain unnecessary data. Keep the choice tied to the content, browser support requirements, and the publishing workflow.
Write meaningful alternative text
Alternative text should communicate the image’s role in context. A meaningful project screenshot may need a brief description of what it demonstrates. A purely decorative flourish can use an empty alternative text value. Do not repeat a long keyword phrase in every image description or describe decorative details that add no information.
If the image contains essential instructions, provide those instructions as real page text as well. Important information should not depend on deciphering a compressed screenshot. This also makes the content easier to translate, search, copy, and use with assistive technology.
Test requests as well as appearance
Use a clean browser session or an appropriate cache configuration when comparing network behaviour. Record the selected source, transferred bytes, viewport, and device-pixel ratio. Then repeat on a wider layout. A visually correct image can still be inefficient, so screenshots alone do not establish that responsive delivery works.
Check for duplicate downloads caused by conflicting preload and image markup. Confirm that the source you intended to prioritise matches the resource the browser selects. Avoid adding preload directives indiscriminately; competing high-priority resources can consume bandwidth needed by other important content.
Use a practical asset budget
Set a project-specific budget for the hero and supporting images after considering content and quality. Treat the budget as a review trigger rather than an excuse to make images unusable. A team might require editorial review before adding another large visual to the first screen. Document the reason for exceptions.
Measure the whole page after changing assets. A large third-party widget or script may still dominate loading, even when image delivery improves. Report the verified reduction in bytes separately from measured rendering changes. This avoids claiming a large speed gain from a small file-size change.
A portfolio exercise
Create a fictional landing page with one hero and three below-fold project screenshots. Prepare two hero crops, several resolution candidates, and a table listing file dimensions and bytes. Explain which images load immediately and which can be deferred. Keep essential project descriptions in text below the screenshots.
Compare the original and revised page under the same test conditions. Record selected image sources, initial transfer, visible stability, and readability. Include an example where excessive compression harms the screenshot so the portfolio demonstrates judgement rather than a simplistic rule that smaller is always better.
Maintenance checklist
Give future editors the master assets, export settings, naming convention, and slot-size notes. Explain which image is the main visual and why it should not be lazy-loaded. If the layout changes, revisit the sizes description and crop choices. Responsive image delivery is connected to the design, not a one-time plugin setting.
Frequently asked questions
Does setting width to 100 percent reduce the download?
No. CSS can shrink the display while the browser still downloads the original file. Appropriate source candidates and formats are needed to address transfer size.
Should every image use lazy loading?
No. Important first-screen images often need early loading. Evaluate each image’s role and position, then verify the resulting network behaviour.
Are modern formats always smaller?
The result depends on the image and quality settings. Compare actual exports and inspect them at realistic sizes rather than assuming an extension guarantees an improvement.