How to Fix a Slow Website
Diagnose a slow website with real user data and browser tools, then fix the bottleneck with targeted, measurable changes.
A slow website has no single universal fix. Start with the affected URL, find whether the delay comes from loading, interaction work, layout shifts, or the server, then change the most likely cause and measure again. Use PageSpeed Insights (PSI) on mobile and desktop, and use Chrome DevTools to inspect the resources and runtime work behind the report.
1. Measure the affected page first
- Choose a URL visitors have reported as slow. Include other URLs that share its template or platform so you can tell whether the issue affects one page or a group.
- Run the URL through PageSpeed Insights for both mobile and desktop. Save the report date, device mode, URL, score, metric values, and notable audits.
- Check whether PSI shows URL-level field data, falls back to origin-level data, or has no field data. Treat these as different evidence states; a missing field panel is not a pass.
- Use Chrome DevTools on the same page to investigate the report’s likely bottleneck. In Network, inspect resource sizes and timing. In Performance, inspect network activity, main-thread work, and the work associated with a slow interaction.
PSI combines Lighthouse lab diagnostics with real-user field data from the Chrome UX Report when enough data exists. Lighthouse is a controlled diagnostic run; it can differ from the experience of actual visitors. PSI field data reflects a trailing 28-day period and can be absent for a page with too few samples or available only at origin level. Use lab audits to decide what to inspect, and field data to understand real users when it is available. Google explains the distinction between PSI lab and field data.
2. Understand what is failing
The current Core Web Vitals are loading, responsiveness, and visual stability metrics. Google’s “good” thresholds apply at the 75th percentile:
| Metric | What it describes | Good threshold | First place to investigate |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main visible content appears | 2.5 seconds or less | The largest visible image or text block and its loading path |
| Interaction to Next Paint (INP) | How quickly the page responds to user input | 200 milliseconds or less | Main-thread work associated with interactions |
| Cumulative Layout Shift (CLS) | Unexpected movement of page content | 0.1 or less | Elements whose size or position changes as content loads |
These thresholds describe field metric categories, not a guarantee that a proposed change will improve a particular site. PSI’s Lighthouse category score is separate: 90 or above is good, 50–89 needs improvement, and below 50 is poor. A score is a diagnostic summary, not a universal measurement of every visitor’s experience. PSI documentation defines the reporting, and web.dev’s performance guidance describes the metrics.
3. Find the bottleneck in the browser
Inspect loading in Network
Open Chrome DevTools, select Network, reload the affected page, and inspect the resource waterfall. Look for a slow document response, large images, delayed or repeated requests, and third-party resources that take a long time. Compare the timing of the largest visible content with the resources it depends on. A large asset is a clue, not proof: confirm that it is relevant to the slow metric before changing it.
Inspect runtime work in Performance
Record a load or interaction in the Performance panel. If the report points to INP, inspect work around the slow interaction and identify whether JavaScript or other main-thread activity occupies the browser. If the report points to CLS, watch which content moves and determine what loading event or geometry change caused it. Make changes to the code or content responsible for the observed work or movement.
Separate page problems from server problems
If the document response is slow or the problem is intermittent, correlate it with traffic, server load, and resource limits. A page can also feel slow because static assets travel a long distance to visitors. Compare evidence across affected URLs and locations before changing hosting or adding a content delivery network (CDN).
4. Apply the fix that matches the evidence
| Symptom | Investigate | Possible targeted change |
|---|---|---|
| Poor LCP | The largest visible content and the requests needed to display it | Optimize an oversized or unnecessary image; investigate delivery or server delay if timings point there |
| Poor INP | Main-thread activity associated with the slow interaction | Reduce or change the specific runtime work the recording identifies |
| Poor CLS | Content whose geometry shifts during loading | Correct the affected layout or loading behavior so content does not move unexpectedly |
| Slow or intermittent document response | Host resource limits, traffic, server load, and hosting configuration | Address the measured constraint; consider a hosting change only when capacity or hardware is the issue |
| Slow static assets for distant visitors | Asset-serving latency and visitor geography | Evaluate a CDN for static assets, checking compatibility and cache invalidation needs |
Change one likely cause at a time where practical. Record what changed, then repeat the same URL and device-mode measurements. Check both the target metric and whether the page still works. Avoid enabling overlapping optimization plugins or making broad changes without a report-backed reason.
5. WordPress-specific checks
WordPress performance can depend on hosting and server load, software versions, theme and plugin configuration, and the number and size of images. Plugin count alone does not prove that plugins are the cause. The WordPress optimization handbook recommends investigating the site’s actual setup and measuring changes.
- Open Tools > Site Health in the WordPress dashboard and review its configuration checks and suggestions. See the Site Health documentation.
- Review whether plugins and theme features are necessary. In a safe environment, selectively deactivate suspected plugins and measure server performance to identify their impact. Do not disable site functionality blindly on a live site.
- Inspect image dimensions, file size, and format. Optimize graphics and consider WebP where your delivery setup supports it.
- Check whether the host’s CPU, memory, I/O, or process limits are being reached. If evidence shows a capacity problem, compare hosting options by available resources, visitor-to-server distance, supported caching and software, management, traffic needs, and migration support.
- Consider caching or offloading static content in the context of the host and site. Check cache invalidation and whether dynamic or personalized pages could be affected.
- Minify CSS or JavaScript only when the page evidence supports it, and retest for visual or functional regressions.
6. Monitor real users and page groups
Use Search Console’s Core Web Vitals report to find recurring issues and groups of affected URLs. Use a live PSI test when investigating one specific URL. Field status can change without a code edit because traffic, image-serving latency, and visitors’ devices, networks, or locations change. When several URLs shift status, compare the affected metric values and audience conditions before attributing the change to a deployment. Google’s Search Console report guidance explains its site-wide role.
7. Troubleshooting common cases
| What you see | Likely explanation | What to do |
|---|---|---|
| PSI has no field data | The URL may not have enough Chrome UX Report samples | Use lab diagnostics for that page and check whether PSI provides origin-level data. Do not interpret missing data as good performance. |
| Lab score is good but visitors report slowness | The simulation and visitor conditions differ, or the affected audience is not represented by the lab run | Review available field data, device mode, page groups, and visitor conditions; inspect the reported URL in DevTools. |
| Field status changes without a deployment | The trailing 28-day sample or visitor mix, traffic, or asset-serving latency changed | Check Search Console groups and metric values, then compare traffic, image delivery, devices, networks, and locations. |
| WordPress remains slow after removing a plugin | The cause may be hosting, server load, theme work, images, other software, or another plugin | Measure the same page again and continue with the Network and Performance evidence rather than assuming plugin count was the cause. |
| A caching or CDN change causes stale or incorrect pages | Cache behavior may conflict with dynamic or personalized content, or invalidation may be incomplete | Review compatibility and invalidation behavior; test affected page types and revert the change if the site serves incorrect content. |
| Optimizing an image does not improve LCP | That image may not be the delayed LCP element, or another part of its loading path is slower | Confirm the actual largest content element and its request timing in the report and Network panel before choosing another fix. |
8. Capture a page while investigating it
A screenshot can make a visual comparison of a page before and after a change easier. It does not replace PSI, field data, or browser performance traces: an image shows rendered appearance, not the timing evidence behind it. You can capture a page with a browser automation setup, or use ScreenshotNeo, a website screenshot API and MCP server for developers.
Or skip the browser setup
Make one GET request to capture a page as an image. Replace the placeholder with your API key; this example captures Stripe as WebP:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpFor the API options and documentation, see the ScreenshotNeo docs. ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say which page verdict and billing status applied. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000, and every feature is available on every plan.
Sign up for 1,000 free screenshots a month, with no card required.
FAQ
Does a high Lighthouse score prove that every visitor has a fast experience?
No. Lighthouse is a lab diagnostic. PSI field data, when available, represents real Chrome users over the preceding 28 days and can tell a different story.
Should I move to a more expensive host to fix a slow website?
Only if measurements point to capacity, server load, or hardware as the bottleneck. Compare resource limits and visitor geography against the evidence first.
How often should I rerun a test?
Rerun after each meaningful, reversible change using the same URL and device mode. Use Search Console to follow site-wide field patterns over time.
Can a screenshot tell me why a page is slow?
No. It can show the rendered result for visual comparison, but timing and runtime causes require performance reports and browser tools.
