Why Is My Website Slow? What to Check Before a Rebuild
A slow website can have several causes: the server takes too long to respond, an image loads late, a script delays clicks, or the CMS struggles to save changes.
Start with the action that feels slow. Record the page, device and conditions, then reproduce it before changing anything.
Describe the delay
Check whether it affects:
- Every page or one page type.
- First visits or repeat visits.
- Mobile, desktop or both.
- Logged-in users or all visitors.
- Ordinary traffic or campaign peaks.
For the CMS, note the editing action. Saving a page may trigger image processing, search indexing or cache clearing. That needs a different investigation from a slow public page.
Compare real-user data with controlled tests
Field data describes real visitors' experiences. Lab tests help you inspect a page under repeatable conditions.
Core Web Vitals measure loading, responsiveness and layout stability. Google's “good” thresholds, assessed at the 75th percentile of visits, are:
| Metric | What it measures | Good threshold |
|---|---|---|
| LCP | When the largest visible content appears | 2.5 seconds or less |
| INP | Responsiveness to interactions | 200 milliseconds or less |
| CLS | Unexpected layout shifts | 0.1 or less |
Google explains the thresholds here.
Record the tool, date, page and device conditions with each result. Keep several runs. Where field data is unavailable, use lab tests to investigate and check again when more data is available.
Check whether PageSpeed Insights is showing data for this URL or the whole origin. When a page lacks enough samples, it can fall back to the site's wider data. Its field report covers a rolling 28 days, so yesterday's fix will not immediately replace the old experience. Google explains the reporting scope.
Follow the evidence
| Symptom | What to inspect |
|---|---|
| Long wait before the page appears | Server response time, processing and cache misses |
| Text appears before the main image | Image size, request timing and loading priority |
| Buttons respond late | JavaScript and work running during the interaction |
| Content jumps as it loads | Image dimensions and content inserted late |
| First visit is slow; later visits are faster | Cache behaviour and asset loading |
| CMS saves take longer over time | Cache size, indexing and background jobs |
A page can have more than one problem. Use the loading sequence and interaction traces to choose what to investigate first. Google's LCP guide and INP guide explain the relevant measurements.
A caching problem from our work
We built ROH Wheels' catalogue and dealer enquiry system with Statamic and Laravel.
Campaign links exposed a caching problem: advertising parameters were creating extra cache entries for the same page. As those entries accumulated, there was more cache data to manage.
The fix depends on what each parameter does. A tracking identifier may leave the page unchanged; a product filter changes the results. Check that distinction before changing the cache rules.
Our Statamic query-string caching article explains the implementation.
What seven sample URLs showed
On 21 September 2026, we checked Statamic 6.31.0 locally using seven versions of a catalogue URL: the plain address, three advertising variations, two size filters and a size filter with an advertising parameter.
We passed them through Statamic's cache URL methods:
| Configuration | Distinct cache URLs |
|---|---|
| Half measure: keep query strings | 7 |
Half measure: keep only the size parameter |
3 |
Full measure: the same size allowlist |
7 |
| Half measure: ignore all query strings | 1 |
The three-URL result kept the unfiltered, size-18 and size-20 views separate. Ignoring every parameter merged those different views. The full-measure result also shows why a setting needs checking against the actual caching strategy.
This measured URL handling, not page speed. Download the inputs and results. Statamic's caching documentation explains the strategy-specific controls.
Make a targeted change and retest
Write down the suspected cause and how you will check it. For example: “The main image loads late because JavaScript inserts it. Put it in the initial page markup and repeat the test.”
Use the same page and conditions for the comparison. Check that the change preserves the site's behaviour: caching still shows the right products, forms still submit, and images retain the detail customers need.
Use the performance worksheet to keep the measurements, changes and results together. Record unsuccessful attempts too.
Decide whether a rebuild is necessary
A large image or faulty cache rule may be fixed without replacing the site. A rebuild becomes more reasonable when the platform prevents required changes or repeated repairs cost too much.
Our redesign versus rebuild guide covers that decision. We can also assess the problem through our website development service or ongoing maintenance.