Practical Website Performance Optimization

A slow website is often a collection of reasonable-looking decisions that add up: a large hero image, three fonts, an animation library, a chat widget, a tag manager, and a carousel that loads all its slides at once.

Performance work starts by finding what is actually expensive. It does not start by installing another optimisation package.

Measure the real experience

Use both lab and field data where possible.

• A local Lighthouse run is useful for spotting obvious issues.
• PageSpeed Insights adds field data when the site has enough traffic.
• Chrome DevTools Performance and Network panels show what is happening on a specific page.
• Search Console Core Web Vitals reports show how real users experience the site.
• A throttled mobile profile is more representative than a fast desktop connection.

Measure the production build. A development server includes tooling and source maps that do not represent the deployed site.

Understand the three Core Web Vitals

The exact thresholds can change over time, but the concepts are stable.

Largest Contentful Paint (LCP) measures when the largest visible content element is rendered. A hero image or a large heading is often the LCP element. Improve it with a faster server, fewer render-blocking resources, a correctly sized image, and a stable layout.

Interaction to Next Paint (INP) measures responsiveness to interactions. Long JavaScript tasks, unnecessary hydration, and heavy event handlers can delay feedback. Keep the main thread free enough to respond.

Cumulative Layout Shift (CLS) measures unexpected movement. Reserve space for images, embeds, fonts, and injected content. An ad or consent banner that pushes the article down is a layout shift.

Fix images first

Images are frequently the largest transfer on a content site.

1. Export at sensible dimensions rather than relying on CSS to shrink a huge file.
2. Use a modern format such as WebP or AVIF, with a fallback where necessary.
3. Provide width and height attributes to reserve aspect ratio.
4. Use srcset and sizes so mobile devices do not download desktop images.
5. Lazy-load below-the-fold images, but do not lazy-load the likely LCP image.
6. Use fetchpriority="high" sparingly on the most important hero image.
7. Check the actual image after compression. A soft, over-compressed portrait is not an optimisation victory.

For a project screenshot, 1440 pixels wide is often enough for a card or case study. A 6000-pixel export is rarely useful on the web.

Treat fonts as a design budget

Each font family and weight adds requests and rendering work. Every font also has a period where the browser has to decide whether to show fallback text, invisible text, or a swap.

A reliable approach:

• self-host the font files you need;
• subset to the languages the site actually uses;
• preload only the most important font file;
• use font-display: swap or a carefully chosen alternative;
• avoid loading six weights when two will do;
• define fallback metrics to reduce movement when the web font arrives.

A distinctive editorial typeface can be a meaningful part of the design. It still has to be paid for in bytes.

Reduce JavaScript before micro-optimising it

JavaScript affects download time, parse time, execution time, and interaction responsiveness. Start with the largest reductions:

• remove unused dependencies;
• split code at route boundaries where it improves the initial load;
• avoid importing an entire icon library when a few named icons are enough;
• delay non-essential widgets until interaction or idle time;
• check whether a client-side animation is worth the runtime cost;
• ensure server-rendered content does not duplicate large data in the client bundle.

A useful test is to disable JavaScript in the browser and inspect the page. If the primary content and navigation are unavailable, the site may still be accessible to crawlers through other measures, but its resilience is lower than it needs to be.

Keep CSS intentional

Large CSS frameworks are not automatically a performance problem, especially when unused styles are removed. Custom CSS can become just as bloated when every page adds another override.

Keep the critical layout stable, avoid chain reactions of layout-affecting properties, and load only the styles the page needs. On a primarily static site, one well-organised stylesheet may be faster than several network requests.

Prevent layout shift

Common causes include:

• images without dimensions;
• banners inserted above the main content;
• web fonts with different metrics from the fallback;
• dynamic content that replaces a small placeholder with a larger block;
• iframes without reserved space;
• animations that change layout rather than transform and opacity.

Reserve the space before the content arrives. A skeleton that matches the final layout is better than a spinner that collapses once data appears.

Avoid premature animation

Motion can make an editorial site feel considered. It can also delay input, consume GPU memory, and create accessibility problems.

Prefer transforms and opacity over properties that trigger layout. Respect prefers-reduced-motion. Stop animations when they are off-screen. Do not make the primary content depend on a scroll-triggered reveal that may never occur.

Build a performance budget

A budget turns “make it faster” into a checkable constraint. It can include:

• initial JavaScript transferred;
• largest image size;
• number of font files;
• LCP on a throttled mobile profile;
• CLS;
• total page weight for key templates.

Set the budget before the redesign, not after. It is easier to reject a heavy widget during design review than to remove it from production.

Measure, change one thing, measure again

Performance work benefits from discipline:

1. Record a baseline.
2. Identify the largest bottleneck.
3. Make one meaningful change.
4. Re-measure under the same conditions.
5. Keep the change only if it improves the user experience.
6. Document any trade-off.

A faster site is not necessarily a better site. The goal is a usable one: content appears quickly, interactions respond, and the page does not jump while someone is trying to read.

For the search side of this work, see Technical SEO Fundamentals for Business Websites. If you are selecting a framework, Choosing the Right Technology Stack for a Business Website covers the broader decisions.