Website performance: 9 clear steps

Stap 0101

Measure first rather than relying on guesswork

Start with at least two kinds of measurement. A laboratory test such as Lighthouse or WebPageTest gives you a reproducible snapshot. Field data from the Chrome User Experience Report or your own monitoring shows what real visitors experience on slower devices and connections. The two do not need to match exactly because they answer different questions.

Don’t just look at one total score. Note the Largest Contentful Paint for the most important visible element, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. The official thresholds come from Google itself: “LCP should occur within 2.5 seconds of when the page first starts loading”, “INP of 200 milliseconds or less” and “CLS of 0.1” (web.dev, Core Web Vitals). They apply per page visit, not to an average: a page counts as “good” when at least 75% of visits stay within the thresholds.

“LCP should occur within 2.5 seconds of when the page first starts loading.” — web.dev, Core Web Vitals

Also record the server response, total JavaScript weight and the largest network requests. That is your baseline — the same approach as in an SEO analysis, but focused on speed.

• Test mobile and desktop on a cold cache.
• Measure a homepage, content page and conversion page separately.
• Keep the waterfall; it shows waiting time and dependencies.
• Repeat the same test after every meaningful change.

Stap 0202

Lower the waiting time before the first HTML

If the browser waits too long for the first document, no front-end optimization can fully hide the delay. Check the Time to First Byte. Slow database queries, heavy server-side plugins, a distant hosting region or dynamic rendering without a cache can delay every page before the browser even starts.

For mostly static marketing pages, static generation is often the simplest win: the HTML is prepared in advance and can be delivered through a global network. For dynamic applications, targeted server caching helps, but never cache personal or shopping-cart data blindly. Measure the origin directly as well, because a CDN can temporarily mask a slow source.

Stap 0303

Make the main image as light as its function allows

Images often account for most of a page’s weight, and the hero image is frequently the LCP element too. The numbers from HTTP Archive’s large-scale annual measurement leave little doubt: the median mobile home page weighed 2,559 KB in July 2025 (Web Almanac 2025, Page Weight); a year earlier that median home page included 900 KB of images and 558 KB of JavaScript (Web Almanac 2024, Page Weight). Never deliver a 3000-pixel-wide photo to a 720-pixel box. Generate responsive variants, use a modern format such as WebP or AVIF and choose the compression level based on the image type. A soft photograph tolerates more compression than an interface image with sharp text.

Do not lazy-load the main image above the fold; the browser should discover it immediately. Images further down the page can load lazily. Always include width and height so the browser reserves space in advance and the layout does not shift. A CMS can store image metadata such as alt text and focal points, but the frontend still needs to generate and serve the correct variants.

Stap 0404

Don’t let critical CSS wait for the rest

The browser needs CSS to draw the first viewport correctly. One large stylesheet containing rules for every page delays that moment. Remove unused rules, split the CSS where it makes sense and avoid a chain of @import files. Keep the critical path smaller than the full component library so relevant content appears sooner without unnecessary style dependencies.

Inlining critical CSS can help in large applications, but it also adds maintenance work. Start with a simpler setup: one well-cached stylesheet, local fonts and no blocking external styles. Then check whether splitting it further produces a measurable gain.

Stap 0505

Ship less JavaScript and run it later

JavaScript costs more than download time. The browser must parse, compile and execute it, usually on the same main thread that also processes your visitor’s input. A bundle that feels harmless on your laptop can cause noticeable delay on an average phone. For responsiveness, Google now measures with INP rather than the older First Input Delay metric: “INP is the successor metric to First Input Delay (FID)” (web.dev, Interaction to Next Paint). Optimizing for an old FID score today means optimizing for a metric that is no longer assessed.

Remove libraries that solve one small interaction, load page-specific functions only where needed and use native HTML for accordions, forms and video where possible. Add defer to non-critical scripts and initialize heavy widgets only after a deliberate interaction. The fastest code is still the code you do not ship.

Stap 0606

Limit web fonts without losing your identity

Five families and twelve weights are rarely necessary. Choose one strong display family and one readable body family, subset the characters you use and load only the weights that appear visibly. Host fonts locally when you want control over caching, privacy and availability.

Preload only the font needed directly above the fold. Too many preloads compete with the main image and CSS. Use font-display: swap so text stays visible while the font arrives, and choose fallback fonts with similar proportions to limit shifting.

Stap 0707

Use caching and a CDN as accelerators, not bandages

Set long cache headers for assets with unique file names. When the content changes, the hash changes and the browser automatically receives the new version. HTML usually needs a shorter cache period because current content matters more than maximum retention.

A CDN brings files closer to visitors and absorbs traffic peaks. But it doesn’t make a file smaller and doesn’t remove blocking code. So first fix the weight and dependencies; then distribute the efficient version.

Stap 0808

Treat every external script as a performance budget

Chat widgets, heatmaps, ad pixels, video players and tag managers often come from other servers. You don’t control their speed and one tag manager can silently start dozens of requests. So inventory every external script with an owner and a clear purpose.

Load marketing tags only after consent. Show a local video poster first, then activate the external player after a click. Remove tools that nobody uses. Treat “may this script be added?” as seriously as “may this feature be added?”

Stap 0909

Make speed part of every release

A one-off optimization does not remain effective by itself. New images, tags and components gradually increase the page weight. Set budgets for JavaScript, images and Core Web Vitals. Make the build warn when a budget is exceeded, and recheck the most important templates after a major change.

Review field data and segments each month: mobile versus desktop, new versus returning visitors and slow versus fast connections. An average can hide a poor experience for mobile users. Performance work is complete only when it is monitored, not when a single Lighthouse run turns green.

Assign every warning to an owner. A red number without a responsible person can remain unresolved, while a concrete ticket with the URL, regression and expected budget is easier to discuss. For new components, include performance in the acceptance criteria: how much extra JavaScript is added, which image becomes the LCP element and what happens on a slow connection? This turns speed from a reactive fix into a normal design decision. Good web design accounts for that from the start: a light, hierarchical layout delivers more speed than any plugin.

Do not forget reliability. A fast first render that then freezes because of a faulty script is still a poor experience. Check console errors, failed requests and timeouts alongside the vitals. A good performance approach makes a page faster, simpler and more predictable.