Keeping page weight in check
⚖️
Avoid website obesity.
Send fewer bytes over the wire. It will cut traffic, load faster, rank better and use fewer resources. Most pages are too fat.
About page weight
Page weight is the total number of bytes a browser downloads to render a page: HTML, images, video, fonts, scripts and styles. It drives three things at once:
- Traffic
- Load time
- Search engines ranking
Slimming a page improves all three with the same edit. Heavy pages are rarely heavy on purpose. A single uncompressed hero image or an oversized background video can outweigh the rest of the page many times over. The fix is almost always to ship the same content compressed.
In his 2015 talk The Website Obesity Crisis, Maciej Ceglowski set a memorably strict yardstick for text-heavy pages:
Text-based websites should not exceed in size the major works of Russian literature.
Images and videos are where most pages blow the budget.
Find the weight
Measure before optimizing. Open the browser developer tools, switch to the Network tab and reload your page. Sort the requests by size and read the transfer total at the bottom. That number is what every visit costs. Check for any large requests that are not necessary.
The traffic and static requests metrics in the dashboard list the URLs that transfer the most, across all visits.
Cross-check with a synthetic audit for a second opinion: the built-in Lighthouse panel, or an external service like Google PageSpeed Insights.
Images
Images are usually the largest share of a page's weight, so this is where most of the savings are. Four levers add up:
- Right-size to the display resolution: a photo shown 800 px wide should not ship at 4000 px.
- Compress: tune the quality setting until the loss is invisible, not until it is zero.
- Use a modern format: WebP and AVIF are much smaller than JPG or PNG at the same quality.
- Use a good encoder: at the same visible quality, the tool matters as much as the setting.
PNGOUT and Guetzli are no longer maintained, and oxipng replaced OptiPNG. Current tools:
- Squoosh: browser based, runs locally, compares formats side by side. Best for one-offs.
- sharp: the Node library for build pipelines. WebP, AVIF and MozJPEG.
- pngquant and oxipng: the PNG pair, lossy pass first, lossless after.
No service needed for a one-off:
cwebp -q 80 photo.png -o photo.webp
pngquant --quality 70-90 logo.png -o logo-min.png && oxipng -o 4 logo-min.png
When a CMS generates images from editor uploads, configure its image transforms to emit sized, compressed WebP variants automatically, so the saving applies to every future upload.
Defer offscreen images with the native loading="lazy" attribute: the browser fetches them only when the visitor scrolls near.
Videos
Video is the single heaviest asset type, handle with care. A short decorative loop and a real content video have different homes.
Decorative loops
A muted background or UI loop can stay self-hosted, as long as it is crunched to a modern codec first. Re-encoding often cuts the file to a fraction of the original with no visible difference:
ffmpeg -i clip.mov -vcodec libx264 -crf 28 -an clip.mp4
In one support case a 9 MiB .mov footer video became a ~2 MiB .mp4 this way. Give it a poster image so the first frame paints immediately, and use autoplay only when the loop is essential: an autoplaying video downloads in full on every visit. Skip animated GIFs; a short video is a fraction of the size.
Content video
Talks, tutorials and other long-form video belong on a dedicated host such as YouTube, Vimeo or Cloudflare Stream. The traffic tiers here are not built to stream it, and an external host also handles adaptive quality and delivery as part of the service.
Web fonts
Web fonts are convenient, but every glyph, weight and format shipped adds bytes. Subset the file to the characters actually used, ship woff2 only, the smallest format with support in every current browser, and limit the number of weights and styles. Set font-display: swap so text stays visible while the font loads.
Scripts and styles
Minify and tree-shake JavaScript and CSS, see frontend performance.
Compression on the wire
Text responses such as HTML, CSS, JavaScript and SVG compress well in transit. GZIP and Brotli shrink them on the server, and the browser expands them on arrival. fortrabbit compresses only after .htaccess turns it on, see GZIP and Brotli.
Compression on the fly runs at the fastest level. Precompressed CSS and JS come out smaller: 26 kB instead of 44 kB for a 253 kB stylesheet.
Keep it slim
Page weight creeps back up as content changes, so make it a recurring check rather than a one-time cleanup:
- Watch the traffic metric over the month for unexpected growth.
- Review image sizes against the resolution they are displayed at.
- Try higher image compression: less weight for the same visible quality.
- Compare the visitor count to the traffic used; a mismatch points at heavy assets.
- Check the Network tab on the most-requested pages.
- Crunch local videos, or outsource the long ones.
A slim page serves more visitors on the same traffic tier and loads faster for every one of them. Not sure where a page's weight is coming from? and we'll take a look.