DM3: Site speed, Core Web Vitals and the technical audit
Images, fonts and mobile-first pages
🎯You'll be able to
Choose image formats and sizes, use lazy loading safely, keep fonts light, and check pages the way a mobile-first crawler sees them.
🏠The everyday picture
You wouldn't post a wall-sized poster to someone who only has a postcard frame. Send the size that fits.
📘What it really is
- Formats: WebP or AVIF for photos (smaller than JPEG at similar quality), SVG for simple drawings and logos, PNG only where needed.
- Sizes: don't send a 3000-pixel photo to a 360-pixel phone. Use
srcsetandsizesso the browser picks a suitable file. - Width and height: set them on every image (or set an aspect ratio in CSS) so space is reserved (CLS, Lesson 2).
-
Lazy loading:
loading="lazy"on images further down the page saves data. Don't lazy-load the main image at the top: it delays LCP. -
Fonts: each weight is a download. Use one or two families, few weights,
font-display: swap, or the system font (MittiMart's choice). -
Mobile-first indexing: search engines mostly crawl and index the mobile version of a page. Content hidden or missing on phones may not count.
-
Accessible and fast go together: a readable page without huge downloads helps people on budget phones and people using assistive technology.
📝A worked example
Input: a product photo uploaded at 3000 × 2250 pixels, 2.4 MB, shown at 320 × 240 on the product page.
Steps:
- Export versions at 320, 640 and 960 pixels wide in WebP.
- Use
srcsetwith those three files andsizes="(max-width: 600px) 90vw, 320px". - Keep
width="320" height="240"and don't lazy-load it, as it's the main image.
Expected output: phones download a file of tens of kilobytes instead of 2.4 MB, and the layout doesn't move. (Illustrative sizes: real savings depend on the photo.)
🌍Where it's used
- Shops generate several sizes of each product photo automatically on upload.
- News sites lazy-load photos further down an article.
- Brands cut font weights when pages feel slow on phones.
📝Case scenario
A travel agency's home page used six weights of two fonts and a 4 MB hero photo. On a 4G phone it took over six seconds to show the headline. Switching to the system font and a 120 KB WebP hero brought it under two seconds in lab tests on the same throttled phone.
🖱️Try it
Save a large photo from your phone and check its file size. Resize it to 640 pixels wide and export it as WebP or a compressed JPEG. Success: the new file is at least five times smaller and still looks fine on a phone.
⚠️Common mistakes
- Uploading camera photos straight to the site. Sign: 2–5 MB images. Fix: resize and compress, ideally automatically.
- Lazy-loading the hero image. Sign: the main image appears late. Fix: lazy-load only images below the first screen.
- Hiding content on mobile. Sign: product details only in the desktop layout. Fix: the same content on every screen size.
🛠️For your project
MittiMart uses small SVG drawings, so its images are light; Project 3 asks for width and height on every one (test 7). Your capstone design notes can describe how real product photos would be handled.
✅Quick check
Should the main image at the top of a page be lazy-loaded?
Show the answer
No; that delays the Largest Contentful Paint. Lazy-load images further down.
Which version of a page do search engines mostly index?
Show the answer
The mobile version.