Optimize Image and Media Loading

A file’s source resolution and encoding determine how many bytes the browser transfers. CSS determines how large that already-selected file is drawn.

For this baseline, a 1440 × 960 source displayed at 720 CSS pixels wide is still requested as the original file. Making it look smaller with CSS does not create a smaller download.

Prepare one learner-owned 3:2 photograph with at least 1440 source pixels of width. Crop locally if needed, but do not upscale it. Keep it as photo-original.jpg.

The offscreen image needs its own URL. The simplest safe choice is a separately named copy of photo-original.jpg called detail-original.jpg. If you use a different detail photograph, keep it 3:2 and at least 1440 source pixels wide; this also ensures you can later create its 960 × 640 version without upscaling.

Create a new local Vite vanilla fixture if you do not already have one, then create public/media/ inside it. Put your two learner-owned files there:

• photo-original.jpg — the 3:2 reference photograph, at least 1440 source pixels wide
• detail-original.jpg — a separately addressed 3:2 offscreen image; a copy of the reference photograph is valid

Replace index.html with the complete baseline below. Replace the sample alt values with text alternatives that accurately describe your own photographs in their article roles. This baseline intentionally has no responsive source list, image dimension attributes, or loading hints; those changes come later.

Build and preview the fixture with the local workflow you used previously. Make an initial recording with a fresh reload and fixed conditions. For example, choose one viewport and keep the same cache state, network throttling, and CPU throttling for later comparisons.

In Network, note both media requests and their transferred amounts. In your performance or Web Vitals evidence, identify the actual LCP element and resource if one is reported. The hero image is a candidate, not an assumption. During a throttled reload, watch whether image arrival pushes article content downward.

In Quality/accessibility notes, include source dimensions, rendered dimensions in CSS pixels, whether each text alternative fits its photograph, and any movement you observed. Use decimal kB for transfer sizes and ms for timings.

Start with your learner-owned 3:2 photograph in public/media/photo-original.jpg. Keep this original available as the baseline; it must be at least 1440 source pixels wide after any crop.

In a local image editor, crop first if needed, then export smaller copies without changing the 3:2 proportion. Do not enlarge a source that is smaller than an export target: upscaling adds pixels but does not restore detail.

These are source-pixel dimensions. They describe the exported files, not the width at which CSS will later display them.

For the common exercise, export JPEG files. At the same dimensions, an editor's compression or quality setting can substantially change transferred bytes and visible detail.

Make two temporary JPEG candidates at 960 × 640 using two different quality settings available in your editor. Compare them at the article's intended display size, then inspect an important detailed area at 100% zoom. Look for softened edges, blocky textures, halos around contrast edges, or color banding.

Choose the smaller candidate only when the photograph still supports its article role. A format or setting is not automatically better merely because its file is smaller.

After choosing the JPEG quality for each target, place the selected files in public/media/. Keep photo-original.jpg and create detail-original.jpg as separately named resources; they may be copies when your photograph is the same.

Record the dimensions and actual file size of every exported variant in decimal kB. File sizes depend on the photograph, editor, quality setting, and metadata, so another learner's values are not targets.

Also record which two same-dimension candidates you compared, the selected quality setting as your editor describes it, and the visible detail that drove your decision.

An image can be responsive and still move the article while it loads. Add width and height attributes that state the image’s real dimensions. Before its pixels arrive, the browser can use their ratio as an aspect-ratio hint and reserve a box.

For the 3:2 Field Notes photographs, width="1440" and height="960" communicate that ratio. They do not force the image to render at 1440 CSS px wide. The existing CSS controls the rendered width; width: 100% and height: auto keep the displayed image proportional inside the article wrapper.

Keep the baseline article geometry unchanged: do not alter .article, figure, figcaption, the article paragraphs, or .detail. In index.html, edit only the two existing opening <img> tags by adding accurate dimensions. Keep each image in its existing <figure> and retain or adapt its text alternative for your own photograph.

In index.html, replace each existing figure with the corresponding version below in the same location. The figure structure, captions, URLs, and surrounding article content stay unchanged; only width and height are added to the image elements.

No CSS replacement is needed if you kept the baseline stylesheet. Verify that this existing rule remains present. It makes the displayed width responsive while the HTML attributes provide the pre-load ratio hint.

srcset gives the browser a set of image-file candidates. With width descriptors, each descriptor states the file’s real source width: the 480 × 320 export is 480w, the 960 × 640 export is 960w, and the 1440 × 960 export is 1440w. A descriptor is not a prediction of displayed width.

sizes answers a separate question: how wide the image is expected to render in CSS pixels. It helps the browser choose a srcset candidate; it does not apply styling or resize the image.

In Field Notes, the article wrapper is viewport width minus 32 px until it reaches its 720 px maximum. The changeover is 752 px because 752 px − 32 px = 720 px.

Do not replace styles.css in this step. Keep the baseline stylesheet and verify that these existing rules remain present. They determine the hero’s rendered width; sizes only describes that result to the browser.

styles.css — existing rules to preserve, not a replacement for the full file

In index.html, replace only the opening <img> tag in the first existing <figure>—the hero image. Keep its existing caption, all article text, the offscreen-image figure, and the existing styles.css unchanged. The src remains a usable fallback. Adapt the alt value to your own photograph while preserving a useful text alternative.

index.html — replacement for the existing hero <img> opening tag

After saving the hero markup and performing a reload, run this in the DevTools Console. You can also confirm the requested file in the Network panel. For comparisons, use fresh reloads and record controlled conditions.

Use your earlier recording, not the image’s size alone, to identify an important initial image. When the Field Notes hero image is visible in the initial viewport and is the measured LCP element/resource, its real image URLs must be present in the initial index.html markup.

That lets the HTML parser discover src and srcset while reading the page. Do not wait to insert the real source after scrolling or after unnecessary JavaScript work. A large image may still take time to transfer and decode, but late discovery adds avoidable waiting before a request can begin.

For the existing hero image, loading="eager" makes its intended treatment explicit. Eager is also the normal image-loading behavior, so this mainly protects important initial content from an accidental lazy setting.

Use fetchpriority="high" only when your recorded initial view identifies this hero as the LCP image or gives equally strong evidence that it is the important initial-content candidate. It is a browser scheduling hint—not a guaranteed request start time and not a substitute for a real source in initial HTML.

In index.html, edit only the opening hero <img> in the first existing <figure>. This keeps the responsive configuration from the preceding step and adds only the two loading-policy attributes. Keep your own adapted alt value if you changed the sample text alternative.

Native lazy loading is for media that is not needed to present the initial article. In Field Notes, the hero image remains available for the initial view; the detail photograph is well below it and is a suitable lazy-loading candidate.

loading="lazy" asks the browser to defer an offscreen image. It does not remove the real URL, accurate dimensions, responsive CSS, or the text alternative. The image must still be ready to appear when a reader reaches it.

Lazy loading answers whether work can be deferred. Fetch priority answers how an eligible request may be scheduled. They are separate decisions.

A browser uses its own distance threshold for native lazy loading. The detail image can therefore appear in Network during the initial load—especially with a tall viewport or particular browser conditions—without proving that loading="lazy" failed.

In index.html, replace only the existing opening <img> tag inside the Later detail figure. Keep the surrounding section, caption, article paragraphs, and styles.css unchanged. The distinct detail URL remains real; its accurate dimensions preserve 3:2 geometry before it arrives.

Adapt the sample alt value only if needed so it remains a useful text alternative for your own photograph and its article role.

index.html — replacement for the existing offscreen image opening tag

preload is a hint about what a browser may fetch before a visitor starts a video. It does not replace native controls or prevent a visitor from playing the clip.

• preload="none" asks the browser not to preload video data. Choose it when a clip is optional and many visitors may never play it.
• preload="metadata" asks for information such as duration and dimensions before playback. Choose it when that information helps a visitor decide whether to play.

Metadata is not necessarily free: its transferred amount depends on the file and browser. Both values are hints, so caching, browser policy, native controls, and pressing Play can change the requests you observe.

Create a separate video.html fixture and place a learner-owned browser-playable video at public/media/clip.mp4. Find the clip’s intrinsic dimensions in local file information, then replace the example width and height values below with the accurate values for your clip. These attributes reserve the correct ratio while CSS keeps the displayed video responsive.

Replace the visible description with a concise transcript or equivalent description when the clip communicates information that is not already available in nearby article text. This fixture deliberately uses native controls and no autoplay. It is separate from the Field Notes image article so the video comparison does not alter that controlled fixture.

Save as video.html in the local Vite fixture. Replace the example dimensions and description before testing.

Make two fresh comparisons: one with preload="none" and one with preload="metadata". In the Network panel, filter for Media, clear the record before each run, and note transferred media before pressing Play. Then press Play once and note the total media transfer shown by your browser.

Use the same record labels as the article measurements: Viewport, DPR, Cache, Network throttling, CPU throttling, Selected image URL, Transferred media, LCP element/resource, LCP time, Layout shifts, and Quality/accessibility notes. For labels unrelated to this video fixture, record not applicable rather than inventing a result.

A request before playback does not automatically mean a policy failed, and no initial request does not mean Play is blocked. If no suitable local video is available, do not claim a local result; use the illustrative table below to make a reasoned policy choice instead.

Make the decision from a like-for-like comparison, not from one unusually fast or slow local run. Keep Field Notes as the same article fixture used for the baseline: the same article copy, image order, wrapper layout, and learner-owned photographs. Integrate the completed image changes in index.html while preserving the existing styles.css layout rules.

Measure the article’s initial viewport before scrolling, then scroll to verify the offscreen image. Keep the video comparison in video.html. A video preload decision answers a separate viewing-intent question; it is not evidence that the article LCP improved.

Repeat article runs under the same recorded conditions. Use a fresh reload when comparing cache conditions, record the initial load before scrolling, and then scroll until the detail image appears.

Interpret the evidence together. Lower transferred media does not guarantee a faster LCP time, and the LCP element can change between runs. Reserved image geometry can remove image-related movement while unrelated content still produces layout shifts. These local recordings are diagnostic evidence, not real-user performance evidence.