Site Speed Optimisation From Basics to Advanced
Feb 24,2026
By SEO ANALYSER
Site speed & Core Web Vitals
Site speed optimisation reduces how long a page takes to load, respond and stay visually stable, from images and caching through to JavaScript, hosting and database work.
Short answer
Fix the largest measured bottleneck first
Start with real user data, identify the slowest stage of the loading process and fix the largest bottleneck first. Images, server response time, JavaScript and third-party scripts are usually the best places to investigate.
Overview
What site speed optimisation covers
Site speed optimisation is the process of reducing how long a website takes to load, respond and become visually stable. It covers everything from image compression and caching to JavaScript execution, hosting performance and database efficiency.
A fast website gives visitors quicker access to information and makes browsing feel smoother. It can also support stronger search visibility by improving page experience and helping search engines crawl a site more efficiently.
However, speed optimisation is not about chasing a perfect test score. Focus on the page speed factors that remove delays for actual visitors across different devices, locations and network conditions.
Why it matters
Why site speed optimisation matters
Website performance influences how easily visitors can use a page. Slow loading, delayed interactions and unexpected layout movement can interrupt the user journey before someone reads the content or completes an action.
Performance is particularly important on mobile devices and for improving mobile UX. A site that appears fast on an office computer may behave very differently on an older phone or a slower mobile connection.
Site speed can affect several areas of website performance:
- User experience: visitors can access and interact with content sooner.
- Conversions: a smoother journey reduces unnecessary friction around forms, enquiries and purchases.
- SEO: Core Web Vitals form part of Google’s broader page experience considerations.
- Crawl efficiency: responsive servers can help search engine crawlers retrieve pages more efficiently.
- Brand perception: a stable and responsive website tends to feel more reliable.
Speed is not the only factor that determines rankings or conversions. Content relevance, accessibility, usability, search intent and technical health still matter. Performance should support these elements rather than replace them.
Core Web Vitals
Understand Core Web Vitals before making changes
Core Web Vitals are metrics designed to measure loading performance, responsiveness and visual stability. The current metrics are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
| Metric | What it measures | Good threshold | Common causes of poor results |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main visible content appears | 2.5 seconds or less | Slow server response, delayed hero images, render-blocking resources and client-side rendering |
| Interaction to Next Paint (INP) | How quickly the page responds to user interactions | 200 milliseconds or less | Long JavaScript tasks, complex rendering and heavy third-party scripts |
| Cumulative Layout Shift (CLS) | How visually stable the page remains | 0.1 or less | Images without dimensions, injected content, adverts, embeds and unstable font loading |
The thresholds should be evaluated at the 75th percentile of page visits. This means the experience needs to remain good for most users, not only for someone testing the page on a fast computer and connection.
Lab data and field data are different
Lab data is collected in a controlled test environment. It is useful for diagnosing specific loading problems and comparing changes under consistent conditions.
Field data comes from real visitors. It reflects different devices, network speeds, locations, cache states and interactions. Field data is usually more useful for understanding whether users genuinely experience a fast website.
Use both types of data. Field data identifies real-world problems, while lab tests help explain what may be causing them.
Speed audit
Start with an accurate site speed audit
Testing a single homepage once does not provide a reliable view of site performance. A practical website audit should cover several representative pages, because websites use different templates, plugins, scripts and content types.
A practical audit should include:
- 01
Select important page types
Include the homepage, service pages, articles, product pages and conversion pages.
- 02
Review field data first
Check available field data before relying on a simulated performance score.
- 03
Run repeatable lab tests
Test under mobile and desktop conditions with comparable settings.
- 04
Inspect the request waterfall
Identify delayed or oversized resources in the network timeline.
- 05
Separate front-end from server issues
Distinguish CSS, JavaScript and image problems from hosting, server and database problems.
- 06
Record a baseline
Capture results before making changes so later tests remain comparable.
- 07
Retest after each meaningful change
Re-run the same pages after each meaningful optimisation.
Avoid changing several systems at once. If caching, image processing and JavaScript settings are modified together, it becomes difficult to identify which change helped or caused a problem.
Images
Improve images without reducing visual quality
Images often account for a large share of a page’s transferred data. Uploading a high-resolution image and relying on CSS to shrink it can force mobile users to download far more data than necessary.
Resize images close to their maximum display dimensions before uploading them. Use an efficient format such as WebP or AVIF where browser support and the publishing workflow allow it. Compression should reduce file size without creating visible artefacts.
Responsive image markup allows the browser to select an appropriate file for the visitor’s screen. WordPress can generate alternative sizes, but themes and custom components must use those sizes correctly.
Use lazy loading selectively
Lazy loading can delay off-screen images and iframes until they approach the viewport. This reduces unnecessary work during the initial page load.
Do not lazy-load the main image responsible for LCP. The browser should discover and request that resource as early as possible. An important LCP image may benefit from being present in the original HTML and assigned a high fetch priority.
Before compressing every image, identify the actual LCP element. If the main image is discovered late because it is injected by JavaScript or hidden inside a stylesheet, compression alone may not solve the delay.
CSS and JavaScript
Reduce render-blocking CSS and JavaScript
A browser must download, parse and process certain resources before it can display a page. Large stylesheets and synchronous scripts placed early in the document can delay visible content.
Minification removes unnecessary characters from CSS and JavaScript files. It can reduce transfer size, but it does not solve excessive code or inefficient execution by itself.
More meaningful improvements may include:
- Removing CSS and JavaScript that the page does not use.
- Inlining a small amount of critical CSS needed for above-the-fold content.
- Deferring non-essential scripts until the document has been parsed.
- Splitting large bundles so visitors only download code required by the current page.
- Breaking long JavaScript tasks into smaller units.
- Reducing expensive layout calculations and large rendering updates.
Test interactive features after changing script settings. Menus, forms, sliders, filters, analytics and consent controls can stop working when scripts are delayed without checking their dependencies.
Third-party scripts
Control third-party scripts
Analytics platforms, advertising systems, chat widgets, video players, social embeds and tag managers can add network requests and main-thread work. The website owner may not control how efficiently those external scripts operate.
Audit each third-party service and decide whether its business value justifies its performance cost. Remove unused tags, avoid loading the same platform more than once and delay optional features until the visitor needs them.
Embedded videos can be replaced with a lightweight preview that loads the full player after interaction. Chat tools may load after consent or after the main content becomes usable. These decisions should still account for privacy, measurement and accessibility requirements.
Caching and CDN
Use caching, compression and a CDN correctly
Browser caching allows returning visitors to reuse static resources instead of downloading them again. Suitable cache headers can be applied to versioned images, fonts, stylesheets and scripts.
Page caching stores a prepared version of a page so the server does not need to rebuild it for every request. Object caching can reduce repeated database work on dynamic websites.
Brotli or GZIP compression reduces the transfer size of text-based files such as HTML, CSS, JavaScript and SVG. Already compressed formats, including many images and videos, usually gain little from additional server compression.
A content delivery network stores resources on geographically distributed servers. Visitors can receive cached content from a location closer to them, which may reduce network latency. A CDN cannot fully compensate for an inefficient application or a slow origin server, so both layers must be monitored.
Server and WordPress
Improve server response and WordPress performance
Front-end optimisation cannot overcome a consistently slow server. Time to First Byte can be affected by hosting capacity, application processing, database queries, redirects, network latency and cache configuration.
For a WordPress website, investigate:
- Hosting resources and server location.
- PHP and database performance.
- Slow plugins and duplicated plugin functionality.
- Uncached pages and repeated database queries.
- Oversized autoloaded options.
- Scheduled tasks and background processes.
- External API calls made during page generation.
- Redirect chains before the final page loads.
Database optimisation should be based on evidence. Removing revisions or clearing transient data may make a database smaller, but it will not necessarily fix slow queries. Profile the application before making irreversible changes.
Advanced tactics
Apply advanced site speed optimisation
Advanced work should begin after the main bottlenecks have been measured and corrected. Complex techniques can add maintenance costs, so each change should solve a demonstrated problem.
Prioritise the LCP resource
Ensure the LCP resource is discoverable in the initial HTML and requested early. Avoid loading it through delayed JavaScript or applying lazy loading to it. Preloading may help when an important resource would otherwise be discovered late, but unnecessary preloads can compete for bandwidth.
Preconnect carefully
Preconnect can establish an early connection to a critical external origin. It should be limited to origins that the page will use immediately. Adding it to every third-party domain can waste browser resources.
Improve interaction responsiveness
For better INP, reduce unnecessary JavaScript, break up long tasks and avoid large rendering updates after an interaction. Event handlers should perform only the work needed to provide an immediate visual response.
Prevent layout movement
Set explicit dimensions or aspect ratios for images, videos, adverts and embeds. Reserve space for content inserted later and review how web fonts affect text dimensions during loading.
Use modern delivery protocols
HTTP/2 and HTTP/3 can improve connection efficiency, but protocol support does not remove the need to control page weight and script execution. A heavy page remains heavy even when its files travel through a more efficient connection.
Tools
Tools for measuring website performance
Pick tools that report the speed metrics your audience actually experiences, then use the comparison below to decide which diagnostic fits the question you need answered.
| Tool | Best use | What to remember |
|---|---|---|
| Google PageSpeed Insights | Reviewing available field data and Lighthouse diagnostics | Field data and lab data may show different results |
| Google Search Console | Finding groups of URLs with Core Web Vitals issues | Reports group similar pages and are not a live test |
| Chrome DevTools | Analysing network requests, rendering and JavaScript tasks | Results depend on the selected test conditions |
| Lighthouse | Running repeatable lab audits and finding opportunities | A score is diagnostic guidance, not the business objective |
| WebPageTest | Detailed waterfalls, filmstrips and location-based testing | Run several tests before drawing conclusions |
| Real User Monitoring | Tracking actual experiences across devices and networks | Collect data responsibly and segment it carefully |
Ongoing workflow
Build an ongoing performance workflow
Site speed optimisation is not a one-time project. New plugins, design changes, tracking scripts, images and content can gradually reduce performance.
Set a baseline and define practical performance budgets for page weight, JavaScript, image size and Core Web Vitals. Test important templates before deployment and monitor field data after major releases.
A useful workflow is to:
- 01
Measure and record a baseline
Measure representative pages and record the baseline.
- 02
Identify the highest-impact bottleneck
Identify the bottleneck with the greatest user impact.
- 03
Make one controlled change group
Make one controlled group of changes at a time.
- 04
Check functionality and accessibility
Check functionality, accessibility and visual consistency.
- 05
Repeat the original tests
Repeat the original tests under comparable conditions.
- 06
Monitor real-user data
Monitor real-user data as enough new information becomes available.
Prioritise changes by impact, effort and risk. A simple image or caching correction may deliver more value than a complicated architectural change.
SEO Analyser
Where Website Audit fits site speed work
SEO Analyser includes a module named Website Audit. Use it when you need a structured pass over speed-related findings, technical issues, and the pages that matter most for load performance.
FAQs
Site speed FAQs
Is site speed a Google ranking factor?
Google uses page experience signals, including Core Web Vitals, within its ranking systems. However, speed is one consideration among many. Relevant, useful content can still be more important than a small performance advantage.
What should I optimise first?
Start with field data and representative page tests. Fix the largest measured bottleneck first. Common priorities include server response time, the LCP image, excessive JavaScript and expensive third-party scripts.
What is a good website loading time?
There is no single loading-time number that describes the entire experience. For Core Web Vitals, a good LCP is 2.5 seconds or less, a good INP is 200 milliseconds or less and a good CLS is 0.1 or less at the 75th percentile.
Should every image use lazy loading?
No. Lazy loading is suitable for many images below the initial viewport. The main above-the-fold image, particularly when it is the LCP element, should normally be loaded early instead of being delayed.
Will a CDN automatically make my website fast?
A CDN can reduce latency and serve cached resources closer to visitors, but it cannot automatically fix inefficient code, slow database queries, oversized pages or heavy JavaScript. It works best as part of a wider optimisation strategy.
How often should site speed be tested?
Monitor performance continuously where possible and run focused checks after major design, plugin, content, hosting or tracking changes. A regular monthly review can also help identify gradual performance decline.
Summary
Effective site speed optimisation begins with accurate measurement. Use field data to understand real visitor experiences and lab tests to diagnose individual bottlenecks.
Focus first on server response, image delivery, unnecessary JavaScript, third-party scripts, caching and layout stability. Advanced techniques should only be introduced when they solve a measured problem.
Performance must also be monitored over time. A controlled workflow that measures, prioritises, tests and verifies each change will produce more reliable results than chasing a perfect score.
Sources
Sources and further reading
- SEO AnalyserHow Core Web Vitals improve speed, stability and SEO performance
- SEO AnalyserWhat factors affect page speed the most in 2026
- SEO AnalyserYour beautiful website is killing your traffic
- SEO AnalyserImproving mobile user experience UX best practices for SEO
- SEO AnalyserWebsite Audit
