Website Speed: Why Milliseconds Matter

Website speed is not a technical detail for developers to worry about. It is a business issue that directly affects whether visitors become customers.

Research consistently shows that conversion rates drop as load times increase. Google uses page speed as a ranking factor. Users have been trained by fast sites to expect instant response. A slow website is not just annoying; it is actively losing you business.

The Business Case for Speed

Let us be specific about what slow costs you.

Conversion impact

Amazon found that every 100 milliseconds of latency cost them 1% in sales. Google found that a half-second delay reduced traffic by 20%. These are big numbers from big companies, but the principle applies to everyone.

For a local service business, the maths might look like this: 1,000 monthly visitors, 3% conversion rate, £500 average job value. That is £15,000 in monthly revenue from the website. A speed improvement that lifts conversion rate from 3% to 3.5% adds £2,500 per month. Over a year, that is £30,000 from what might be a few hours of optimisation work.

The exact numbers depend on your situation, but the relationship between speed and conversions is well-established. Faster sites convert better.

SEO impact

Google has explicitly stated that page speed is a ranking factor. Since 2021, Core Web Vitals, specific speed and user experience metrics, have been part of their ranking algorithm.

A slow site, all else being equal, will rank worse than a fast site. When you are competing for local search visibility, speed can be the difference between appearing on page one or page two.

User experience impact

Slow pages frustrate users. They create doubt: is this site broken? Is this business legitimate? They erode trust before you have had a chance to earn it.

Fast pages feel professional and reliable. They build confidence from the first interaction. Users may not consciously notice when a site is fast, but they notice when it is slow.

Core Web Vitals Explained

Core Web Vitals are Google's specific metrics for measuring user experience. They focus on loading, interactivity, and visual stability.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the main content to load. Specifically, it times when the largest element in the viewport, usually a hero image or main text block, becomes visible.

A good LCP is under 2.5 seconds. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.

LCP problems usually come from slow server response, render-blocking resources, slow image loading, or client-side rendering that delays content.

Interaction to Next Paint (INP)

INP measures responsiveness: how quickly the page responds when users interact with it. Clicking a button, typing in a form, opening a menu — INP measures the delay between action and response.

A good INP is under 200 milliseconds. Between 200 and 500 milliseconds needs improvement. Over 500 milliseconds is poor.

INP problems usually come from heavy JavaScript that blocks the main thread, long-running tasks, or inefficient event handlers.

Cumulative Layout Shift (CLS)

CLS measures visual stability: whether elements move around as the page loads. You have experienced this when trying to click a button just as something loads above it, pushing the button down and causing a misclick.

A good CLS is under 0.1. Between 0.1 and 0.25 needs improvement. Over 0.25 is poor.

CLS problems usually come from images without dimensions, ads or embeds that load late, fonts that cause text to reflow, or dynamically injected content.

Measuring Your Site Speed

Before optimising, measure. You need to know where you stand and where problems lie.

Google PageSpeed Insights

PageSpeed Insights (pagespeed.web.dev) is Google's free tool for measuring Core Web Vitals and identifying issues. Enter your URL and get scores for mobile and desktop along with specific recommendations.

Focus on the mobile score. That is what Google uses for ranking, and mobile performance is typically worse than desktop.

Google Search Console

Search Console shows Core Web Vitals data for your actual visitors, not lab tests. The "Core Web Vitals" report under "Experience" shows which pages pass, need improvement, or fail.

This real-user data is valuable because it reflects actual experience across different devices and connections.

GTmetrix

GTmetrix provides detailed performance analysis with waterfall charts showing exactly what loads when. This helps identify specific bottlenecks: which files are slow, which requests block rendering, where delays occur.

The waterfall view is particularly useful for diagnosing problems that aggregate scores do not reveal.

WebPageTest

WebPageTest offers advanced testing options: different locations, different connection speeds, video capture of loading. For complex problems, it provides forensic detail.

Lighthouse

Lighthouse is built into Chrome DevTools (F12, Lighthouse tab). It runs the same tests as PageSpeed Insights but locally on your machine. Useful for testing changes before deployment.

Common Speed Problems and Fixes

Most slow websites share common problems. Fix these before pursuing exotic optimisations.

Unoptimised images

Images are typically the heaviest elements on a page. Unoptimised images are the single most common cause of slow sites.

The problem: Images uploaded directly from cameras or phones are massive. A 4000x3000 pixel photo at full quality might be 5MB. If your page has five such images, that is 25MB of data to download.

The fix: Resize images to the dimensions they will actually display. A hero image displayed at 1200 pixels wide does not need to be 4000 pixels wide. Compress images using tools like TinyPNG, Squoosh, or ImageOptim. Use modern formats like WebP, which provides better compression than JPEG. Implement lazy loading so images below the fold load only when needed.

A page with ten properly optimised images might be 500KB total. The same page with unoptimised images might be 30MB. The difference in load time is enormous.

Too many HTTP requests

Every file your page needs, HTML, CSS, JavaScript, images, fonts, requires a separate request to the server. Each request has overhead. Pages with hundreds of requests are inherently slow.

The problem: Sites with numerous plugins, multiple tracking scripts, many decorative images, and fragmented CSS/JS files make too many requests.

The fix: Combine files where sensible. Remove unused scripts and plugins. Question whether each resource is necessary. Inline critical CSS. Use CSS sprites for multiple small images.

Render-blocking resources

Render-blocking resources are scripts and stylesheets that must fully load before the page can display. While they load, visitors see nothing.

The problem: JavaScript and CSS files in the document head block rendering by default. Large files or files loaded from slow servers delay everything.

The fix: Defer non-essential JavaScript so it loads after the page renders. Inline critical CSS (the styles needed for above-the-fold content) and load the rest asynchronously. Move scripts to the end of the body where possible.

Slow server response

Before anything else can happen, the server must respond to the initial request. Slow servers delay everything that follows.

The problem: Budget shared hosting, overloaded servers, inefficient server-side code, and database queries that take too long all slow server response.

The fix: Upgrade hosting if server response time (TTFB, Time to First Byte) is consistently over 600ms. Use caching to serve static content without regenerating it for each request. Optimise database queries if using a CMS. Consider a CDN to serve content from locations closer to visitors.

WordPress-specific issues

WordPress sites have particular speed challenges due to the platform's architecture.

The problem: Each plugin adds overhead. Themes often include features you do not use. The database grows and slows over time. Poorly coded plugins cause conflicts and slow execution.

The fix: Audit and remove unused plugins ruthlessly. Choose lightweight themes or custom builds. Install a caching plugin (WP Super Cache, W3 Total Cache, or WP Rocket). Use a database optimisation plugin. Consider whether WordPress is the right platform for your needs.

A WordPress site with 30 plugins, a heavy theme, and no caching might take 6 seconds to load. The same content on a lightweight platform with good caching might load in under 2 seconds.

Third-party scripts

External scripts for analytics, chat widgets, social media embeds, advertising, and tracking add up quickly.

The problem: Each third-party script requires requests to external servers you do not control. If those servers are slow, your page is slow. Some scripts are bloated or poorly optimised.

The fix: Audit every third-party script. Do you actually use that chat widget? Is the social media feed adding value? Remove what you do not need. Load remaining scripts asynchronously so they do not block page rendering. Delay non-essential scripts until after the page has loaded.

Web fonts

Custom fonts improve design but cost performance. Each font file must download before text displays, and some font loading strategies cause text to flash or reflow.

The problem: Multiple font weights and styles multiply file downloads. Font files can be large. Poor loading strategies cause layout shift or invisible text.

The fix: Limit font weights and styles to what you actually use. Use font-display: swap to show fallback text while fonts load. Preload critical fonts. Consider system fonts for body text, which require no download at all.

Quick Wins for Faster Sites

If your site is slow, start with these high-impact changes.

Compress and resize all images. This alone often halves page weight.

Enable caching. Browser caching for repeat visitors, server caching for faster generation.

Remove unused plugins and scripts. Audit everything; be ruthless.

Upgrade hosting if TTFB is over 600ms. Cheap hosting has hidden costs.

Defer non-critical JavaScript. Let the page render before loading extras.

Use a CDN. Serve assets from locations closer to visitors.

Optimise the critical rendering path. Inline critical CSS; defer the rest.

The Speed-Cost Balance

Extreme speed optimisation has diminishing returns. Going from 5 seconds to 2 seconds is valuable. Going from 2 seconds to 1.8 seconds is nice but less impactful. Going from 1.8 seconds to 1.6 seconds is probably not worth significant effort.

Focus on meaningful improvements. If your Core Web Vitals are all green and your pages load in under 2 seconds, you have diminishing returns territory. If anything is red, prioritise fixing that.

Speed improvements should also consider maintenance burden. A complex caching setup that shaves 200ms but breaks every time you update content may not be worth it. Sustainable improvements beat fragile optimisations.

Speed and Modern Web Development

The technology choices underlying your website significantly affect achievable speed.

Traditional server-rendered sites (like WordPress) generate HTML on each request. This is flexible but adds server processing time.

Static sites (built with tools like Astro, Hugo, or Next.js static export) generate HTML at build time. There is no server processing per request; the server just delivers pre-built files. This is inherently fast.

Content delivery networks (CDNs) serve files from global locations. A visitor in Newcastle gets files from a UK server, not a US one. Latency drops dramatically.

Modern image formats and automatic optimisation can handle images intelligently without manual work.

When planning a website project, consider speed as a fundamental requirement, not an afterthought. The architecture decisions made at the start have more impact on speed than optimisation efforts bolted on later.

Measuring Improvement

After making changes, measure again. Compare before and after scores. Check that improvements persist over time.

PageSpeed Insights scores can fluctuate based on test conditions. Run multiple tests and look at averages. The Core Web Vitals data in Search Console reflects real user experience over 28 days.

Monitor ongoing performance. Speed can degrade as content is added, plugins are installed, or third-party scripts change. Regular checks catch regression before it becomes severe.

Speed is not glamorous. It does not make exciting case studies or impressive before-and-after screenshots. But it quietly affects every visitor's experience, every conversion, and every search ranking. It is one of those fundamentals that, done well, makes everything else work better.