Loading Performance

Most of a page's loading speed is decided by its HTML: what it asks for, in what order, and how big it is.

The critical rendering path

1. The browser receives the HTML and starts parsing.
2. It discovers resources as it goes. The preload scanner looks ahead in the raw HTML for src and href values and starts downloads early — even while a script blocks the main parser.
3. Stylesheets in the head block rendering — nothing is painted until they're loaded.
4. Plain scripts block parsing until they're downloaded and run.
5. The first paint happens; images, fonts, and deferred scripts fill in.

Core Web Vitals

Google's user-experience metrics, measured from real visitors:

HTML decides a lot of each:

• LCP: make the main image discoverable in the HTML (not injected by JavaScript or hidden in a CSS background), don't lazy-load it, give it fetchpriority="high", and serve a correctly sized file.
• CLS: width and height on every img, video, and iframe; reserve space for ads and embeds; avoid inserting banners above existing content.
• INP: less JavaScript — defer it, split it, and use built-in elements (details, dialog, popover) instead of script-heavy widgets.

A fast page head

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Corner Bakery</title>
    <link rel="preconnect" href="https://cdn.cornerbakery.example" crossorigin>
    <link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
    <style>/* small critical CSS for the first screen */ body { margin: 0; font-family: system-ui, sans-serif; }</style>
    <link rel="stylesheet" href="/css/site.css">
    <script src="/js/app.js" type="module"></script>
  </head>
  <body>
    <img src="/img/hero-1200.webp" alt="Fresh loaves on the counter" width="1200" height="600" fetchpriority="high">
    <h1>Fresh bread, every morning</h1>
    <img src="/img/map.png" alt="Map to the shop" width="800" height="400" loading="lazy">
    <iframe src="https://maps.example/embed" title="Interactive map" width="800" height="400" loading="lazy"></iframe>
  </body>
</html>

Weight

• Compress HTML, CSS, and JavaScript on the server (gzip or Brotli) — text shrinks dramatically.
• Minify in production. Our HTML Minifier and CSS Minifier do it in the browser; build tools do it automatically. Check page weight with the Page Size Checker.
• Very large DOMs (thousands of elements) slow down styling, layout, and scripts. Paginate long lists or render them in chunks.

content-visibility

CSS content-visibility: auto lets the browser skip rendering work for off-screen sections until they're needed — a large win for long pages. See the CSS course.

Measure

• Lighthouse and PageSpeed Insights — lab measurements plus real Chrome user data when a site has enough traffic.
• The browser Performance panel — see exactly what blocked what.
• The web-vitals JavaScript library — measure real visitors.

Measure before and after every change: the right fix depends on what's actually slow.