Web Performance: What Actually Makes Pages Fast

9 minute read · Last updated 2026-10-31 · Written and reviewed by the Code.House editorial team

Performance work has a steep pay-off curve: a few changes produce most of the gain, and everything after that is increasingly fine-grained. This guide covers the few.

The three metrics that matter

Google publishes these as Core Web Vitals and uses field data from real visits, not lab tests. A page that scores well in a lab tool and badly in the field is usually suffering on slow mobile connections.

Images: the usual culprit

On most content sites, images are the largest share of bytes shipped.

• Serve AVIF or WebP with a fallback. The same photo is often 40–70% smaller than a JPEG at equal quality.
• Set width and height attributes, or an aspect-ratio in CSS. This reserves the space and prevents layout shift.
• Add loading="lazy" to images below the fold, and never to the hero image — lazy-loading the LCP element delays it.
• Resize to the largest size actually displayed. A 4000-pixel photo in a 600-pixel slot wastes most of its bytes.

<img src="hero.avif" width="1200" height="675" alt="..." fetchpriority="high">
<img src="thumb.avif" width="400" height="300" alt="..." loading="lazy" decoding="async">

JavaScript discipline

JavaScript is expensive twice: downloading it, then parsing and executing it on a phone CPU. The practical rules:

• Load scripts with defer so parsing does not block rendering.
• Split heavy features so code loads when used, not on first paint — an editor, a map, a chart library.
• Prefer one well-chosen dependency over five overlapping ones, and check the install size before adding anything.
• Replace third-party embeds with facades: show a static thumbnail and load the real iframe on click. A single video embed can otherwise pull in hundreds of kilobytes.

Fonts and third parties

Custom fonts delay text. Use font-display: swap so text renders immediately in a fallback, preconnect to the font host, and limit yourself to two families and the weights you actually use. Each extra weight is another file.

Third-party tags — analytics, chat widgets, tag managers, advertising — are the most common cause of a fast site becoming slow, because they are added one at a time by different people. Audit them periodically and remove what no longer earns its place. Advertising scripts in particular should have their containers sized in advance so that ads do not push content down as they fill.

Measuring honestly

Test on a mid-range Android phone over throttled 4G, not a desktop on office wifi. Lighthouse in Chrome DevTools gives a lab score and specific recommendations; PageSpeed Insights adds field data from real Chrome users when a page has enough traffic. Record the number before and after each change — performance work without measurement turns into superstition quickly.

Common questions

Does a faster site really change revenue?

Published case studies from large retailers and publishers consistently report conversion gains from latency reductions, though the magnitude varies by industry and starting point. Measure on your own traffic rather than assuming a published figure transfers.

Is server-side rendering always faster?

It usually improves the first paint and is better for crawlers. It does not fix a heavy JavaScript bundle, since the page still has to hydrate.

Keep reading

Spotted something out of date? Send a correction — guides are revised rather than quietly deleted.