I provide website speed optimisation for Wigan businesses with slow, heavy or poorly responding websites. The work starts by measuring where time is actually being lost, then addresses the relevant causes such as server response, oversized images, render-blocking resources, JavaScript, fonts, third-party scripts, caching or WordPress configuration.
Find out what is making your website slow before trying to fix it
Website Speed Optimisation Wigan
Contact Me
Call me or request a call back.
Tel: 07784 293809
Search Focus
305 Wigan Road
Ashton-in-Makerfield
Wigan
WN4 9ST
Find me on social media…
Website speed optimisation should fix bottlenecks rather than chase a score
A slow website can have several different causes. The server may take too long to return the first HTML, the browser may wait for a large hero image, JavaScript may block the main thread or content may move unexpectedly while fonts, adverts or embedded elements load.
That is why a PageSpeed Insights score on its own is not a diagnosis.
Speed optimisation means identifying which resources and processes are delaying the user experience, deciding which changes are technically and commercially sensible, implementing them carefully and measuring the result afterwards.
Core Web Vitals
Server Response
Image Optimisation
JavaScript & CSS
Caching & Delivery
Third-Party Scripts
How do you diagnose a slow website?
The first step is understanding what the performance data actually represents.
Field data reflects visits from real users, including differences in devices, connections and interactions. Laboratory data runs a controlled test and is particularly useful for diagnosing reproducible technical problems.
- Chrome User Experience Report data reflects real users where sufficient data exists
- PageSpeed Insights can present both field and lab information
- Lighthouse provides controlled diagnostic testing
- Chrome DevTools can help trace individual loading and scripting problems
- Search Console groups URLs using Core Web Vitals field data
A high laboratory score does not prove that every real visitor receives an equally fast experience. Equally, one slow test from one location does not establish that every user has a slow website.
Core Web Vitals measure three different parts of page experience.
Google’s current recommended “good” thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, assessed at the 75th percentile.
- LCP measures when the largest visible content element renders
- INP measures responsiveness to user interactions
- CLS measures unexpected movement of visible page content
A page can pass one metric and fail another because the causes are different. Compressing an image may improve LCP while doing little to solve a long JavaScript task affecting INP.
Slow rendering can begin before any visible content reaches the screen.
Time to First Byte, often abbreviated to TTFB, measures part of the delay before the browser receives the first byte of the response. It can be influenced by several stages rather than one single server setting.
- DNS and connection setup
- Redirect chains
- Server processing
- Database queries
- Uncached WordPress execution
- Geographical network distance
If the initial document arrives slowly, later front-end optimisation has less time available to achieve a fast Largest Contentful Paint.
The browser cannot render a useful page until it has received and processed the resources needed for that part of the layout.
Network analysis can show which files are requested, how large they are, when they start loading and what other work they depend on.
- Images
- Stylesheets
- JavaScript
- Web fonts
- Video and embedded media
- Third-party resources
The largest file is not automatically the highest-priority fix. A smaller render-blocking or high-priority resource can sometimes delay the visible page more than a much larger file loaded later.
Downloading JavaScript is only part of its performance cost; the browser also has to parse and execute it.
Long tasks can occupy the browser’s main thread and delay reactions to user input. This is particularly relevant to Interaction to Next Paint.
- Large JavaScript bundles
- Page-builder scripts
- Third-party tags
- Complex interactive components
- Repeated event handlers
- Heavy front-end calculations
A laboratory tool can highlight Total Blocking Time as a useful diagnostic metric, but INP itself depends on real interactions and is fundamentally a field metric.
What usually makes WordPress websites slow?
A page can become unnecessarily heavy when assets are uploaded or embedded without considering how they are delivered.
This is common on websites where content has been added gradually by several users over a number of years.
- Images uploaded at dimensions far larger than their displayed size
- Uncompressed photographs
- Autoplay or background video
- Large sliders containing several hero images
- Multiple font families and weights
- Embedded maps, feeds or video players
Optimisation should preserve the purpose of the media. Reducing every photograph until visible quality becomes poor is not a successful performance strategy.
WordPress plugins can add front-end assets and server-side processing even when only part of their functionality is being used.
A slow WordPress site is not necessarily slow because it has a particular number of plugins. Ten efficient plugins can behave very differently from one poorly implemented extension.
- Duplicate optimisation tools
- Unused features loading sitewide
- Plugins making expensive database queries
- Extensions adding large script libraries
- Old plugins using inefficient approaches
The useful question is what each extension costs and what business function it provides, not whether an arbitrary plugin-count target has been exceeded.
Visual builders make complex layouts easier to manage, but the finished page can still contain more markup, CSS and scripts than a simpler implementation would require.
WPBakery, Elementor, Divi and theme-specific builders all operate differently, so performance work needs to consider the actual installation rather than blaming a builder name alone.
- Deeply nested rows and columns
- Unused widgets or modules
- Animations applied throughout the page
- Large global style files
- Multiple slider or gallery libraries
- Theme features loaded on pages that do not use them
Rebuilding an entire website is not automatically necessary. In many cases the heaviest templates and components can be improved selectively.
Front-end optimisation cannot completely compensate for a server that consistently takes too long to generate responses.
WordPress may execute PHP and database queries for each uncached request. Caching can avoid repeating some of that work, but the correct setup depends on the website.
- Slow application processing
- Insufficient server resources
- Uncached pages
- Poorly configured object caching
- Slow database operations
- Unnecessary redirect chains
Dynamic areas such as baskets, accounts and personalised pages may require different cache rules from static service pages, so aggressive caching should not be enabled blindly.
Website Speed Optimisation Work
Website Performance Audit
For businesses that know the website is slow but need the actual bottlenecks identified before changes are made.
Diagnosis First
- PageSpeed Insights review
- Core Web Vitals assessment
- Field and lab data comparison
- Network request review
- Largest Contentful Paint investigation
- JavaScript and main-thread review
- Image and font analysis
- Third-party script review
- Server-response observations
- Prioritised recommendations
For WordPress Websites
WordPress Speed Optimisation
For an existing WordPress website where measurable performance problems can be traced to the theme, plugins, media, scripts, caching or hosting setup.
Site Specific
- Image optimisation
- Cache configuration
- Plugin review
- Theme and builder assessment
- Script-loading changes
- CSS delivery improvements
- Font optimisation
- Database investigation where relevant
- Hosting-related recommendations
- Before-and-after testing
Core Web Vitals Improvements
For websites where field data identifies specific LCP, INP or CLS problems that need deeper technical investigation.
Metric Led
- LCP element diagnosis
- Resource prioritisation
- INP investigation
- Long-task analysis
- CLS source identification
- Image dimension fixes
- Font-loading review
- Third-party impact assessment
- Real-user data comparison
- Post-change measurement
Core Web Vitals work is not a promise of identical scores for every visit. Field performance varies with devices, networks, user behaviour and resources outside the website owner’s direct control.
Website Speed Optimisation FAQs
Answers to common questions about slow websites, PageSpeed Insights, Core Web Vitals and WordPress performance.
Website speed optimisation is the process of diagnosing and reducing unnecessary delays in loading, rendering and interacting with a website.
It can involve hosting, server processing, caching, images, CSS, JavaScript, fonts, third-party resources and the way the website itself has been built.
The correct work depends on measured bottlenecks rather than applying the same optimisation plugin or checklist to every site.
Yes. I provide website speed optimisation for Wigan businesses that need performance problems investigated and improved.
Most technical performance work can be completed remotely because testing and implementation take place through the website, hosting environment and development tools.
The website can therefore serve customers locally or nationally while the business itself is based in Wigan.
Core Web Vitals are Google’s current set of user-experience performance metrics covering loading, responsiveness and visual stability.
Largest Contentful Paint measures loading performance, Interaction to Next Paint measures responsiveness and Cumulative Layout Shift measures unexpected visual movement.
They should be assessed using appropriate field data where available because real visitors experience different devices, networks and interactions.
Google currently classifies an LCP of 2.5 seconds or less as good when assessed at the 75th percentile of page visits.
Largest Contentful Paint is the render time of the largest qualifying image, text block or video visible in the viewport.
Poor LCP can result from slow server response, late resource discovery, slow resource loading or delays rendering the LCP element.
Google currently considers an INP of 200 milliseconds or less good at the 75th percentile.
Interaction to Next Paint measures how responsive a page feels across user interactions rather than how quickly the initial page first appears.
Long JavaScript tasks and excessive main-thread work are among the areas that may contribute to slow interaction response.
Google currently defines a CLS score of 0.1 or less as good at the 75th percentile.
Cumulative Layout Shift measures unexpected movement of visible content.
Common causes can include images without reserved dimensions, late-loading fonts, dynamically inserted content and embedded components that change size after the surrounding page has already rendered.
PageSpeed Insights is a Google tool that reports website performance information and diagnostics.
Where sufficient data exists, it can show Chrome User Experience Report field data alongside a Lighthouse laboratory test.
The two datasets answer different questions, so they should not automatically be expected to produce identical results.
Laboratory performance results can vary because loading and processing conditions are not perfectly identical on every run.
Network timing, server response, third-party services and other variables can affect an individual test.
It is more useful to look for persistent bottlenecks and meaningful trends than to repeatedly retest until one particularly high score appears.
No. A perfect Lighthouse score is not a requirement for a useful or commercially successful website.
Some functionality has a legitimate performance cost. Removing analytics, ecommerce features or other necessary tools solely to obtain a higher synthetic score may make the website less useful.
The priority should be genuine user experience and the highest-value performance problems rather than a score pursued without context.
Mobile testing can expose limitations that are less obvious on a faster desktop environment.
A page may require the same scripts, styles and media while the simulated device has less processing capacity and different network characteristics.
This is one reason performance problems involving JavaScript and heavy resources can appear more severe in mobile tests.
Field data comes from real users, while lab data comes from a controlled test environment.
Field data can capture variation in real devices, network conditions and interactions. Lab tests are reproducible enough to help identify technical causes and test changes before deployment.
Both are valuable, but they should not be interpreted as though they represent the same measurement conditions.
Search Console and Lighthouse rely on different forms of measurement.
Search Console’s Core Web Vitals reporting is based on field data and groups URLs with similar characteristics, while Lighthouse runs a laboratory test of an individual page.
A Lighthouse improvement therefore does not instantly rewrite historical real-user data in Search Console.
Page experience and Core Web Vitals can form part of the wider search picture, but website speed should not be treated as a replacement for relevance, useful content and other important search signals.
A fast page that does not satisfy the search intent is not made competitive simply by achieving excellent performance metrics.
Speed optimisation is most valuable when it improves the user experience while preserving the content and functionality people actually need.
No. Improving Core Web Vitals does not guarantee a particular ranking increase.
Search rankings depend on many factors, and performance is only one part of the overall website and search environment.
Performance work should therefore be justified by user experience and technical quality as well as its potential SEO value.
A slow WordPress website can have several causes, including server response, plugins, themes, page builders, large media files, scripts, database work or third-party resources.
The WordPress platform itself is not enough to identify the bottleneck.
Testing is needed to determine whether the main delay occurs on the server, during resource loading, while rendering the page or after users begin interacting with it.
The number of plugins alone is not a reliable measure of performance.
A plugin can have almost no front-end impact or it can introduce substantial queries, scripts and requests. Several efficient plugins may therefore cost less than one badly behaving extension.
Plugins should be assessed according to what they load and what processing they perform.
Caching can provide substantial improvements where repeated server work is part of the problem, but it does not solve every performance issue.
A cached page can still contain oversized images, excessive JavaScript, slow third-party embeds and layout shifts.
Caching should therefore form part of the diagnosis rather than being treated as a universal fix.
Browser caching allows suitable resources to be reused instead of being downloaded again on every visit.
Cache behaviour is controlled through response headers and can be particularly useful for assets such as images, stylesheets, scripts and fonts that do not change on every request.
Assets still need an appropriate strategy for changes so visitors are not left with obsolete files indefinitely.
Page caching stores a previously generated response so the server does not have to rebuild the same page from scratch for every suitable request.
This can significantly reduce application processing on many WordPress websites.
Dynamic content such as customer accounts, baskets or personalised pages may require exclusions or more specialised caching behaviour.
A content delivery network can reduce the network distance for suitable resources and may provide additional caching or delivery features.
The benefit depends on the website, its audience, origin hosting and which resources are served through the CDN.
A CDN cannot automatically correct inefficient application code or excessive browser-side processing.
There is no single image format that is best for every image.
Modern formats such as WebP and AVIF can provide efficient compression in appropriate circumstances, while format choice should still account for browser support, visual quality, transparency, image type and the website’s image-processing setup.
Correct dimensions and sensible compression can be as important as simply changing the file extension.
No. Lazy loading is useful for many images that begin below the visible viewport, but delaying an important above-the-fold image can be counterproductive.
If the main hero image is the Largest Contentful Paint element, making its discovery or loading unnecessarily late can worsen LCP.
Loading strategy should therefore reflect where the image appears and how important it is to initial rendering.
Web fonts can add additional network and rendering work, particularly when a website loads many families, weights or external font files.
Performance can be improved by reducing unnecessary variants and reviewing how fonts are requested and displayed.
The correct approach also needs to preserve the site’s typography and branding requirements.
They can. Consent platforms, analytics, advertising pixels and other third-party scripts may add downloads and JavaScript execution.
That does not mean legitimate consent or measurement systems should simply be removed for performance reasons.
The implementation should instead be reviewed so unnecessary duplication and avoidable loading costs are reduced while required functionality remains intact.
They can add significant media and scripting costs depending on how they are implemented.
A slider may require several large images and JavaScript before or during the initial view, while background video can add considerably more data than a static image.
The performance cost should be weighed against whether the component genuinely improves the page for users.
Yes, but WooCommerce performance work needs to respect dynamic ecommerce functionality.
Products, baskets, checkout, customer accounts, payment gateways and extensions can introduce requirements that do not exist on a simple brochure website.
Cache rules and script changes should therefore be tested against actual purchasing journeys rather than judged only on the homepage score.
Yes. Websites built with visual page builders can often be improved without automatically rebuilding the entire site.
Potential work can include simplifying heavy layouts, reducing unnecessary components, optimising assets and reviewing which theme or builder resources load on individual pages.
The achievable result depends on the existing design, theme and functionality.
The cost depends on what is causing the performance problem and how much development is required to correct it.
Compressing and resizing a set of images is very different from diagnosing slow server processing, restructuring heavy templates or reducing the impact of several integrations.
An initial performance review provides a better basis for quoting the required work than pricing solely from a PageSpeed score.
The timescale depends on the number and complexity of the bottlenecks found.
Some improvements can be implemented relatively quickly, while theme changes, server investigation, complex JavaScript or third-party dependencies may require more testing.
Field metrics can also take longer to reflect changes because they depend on subsequent real-user visits rather than a single immediate laboratory test.
No fixed PageSpeed score should be guaranteed without considering the website and the conditions under which the test runs.
Scores can be affected by third-party resources, server timing and test conditions, while business-critical functionality may have a legitimate performance cost.
The objective should be measurable improvement and a better user experience rather than engineering the site solely around one synthetic number.
No. Core Web Vitals field data reflects real visitors using different devices, connections and interaction patterns.
The website can be improved to address identified technical causes, but external scripts, changing content, hosting behaviour and real-world conditions can still influence measured performance.
Performance should therefore be monitored after changes rather than treated as permanently solved by one test.
The website URL is the most useful starting point because initial public performance testing can identify obvious bottlenecks.
Deeper work may later require:
- WordPress administrator access
- Hosting or server information
- Cache or CDN access
- Details of important third-party services
- Information about recent changes
Access should only be requested when it is genuinely needed for diagnosis or implementation.