Check Real Customer Page Speed: Practical before & after checks for Birmingham service websites

Local changes to your website — new images, a redesigned service page, or a faster hosting plan — should make life easier for customers. But lab tests don’t always tell the full story. This guide shows how to measure page speed that real customers experience, both before and after changes, with a short checklist, a hands-on workflow and practical tips for Birmingham, Solihull and West Midlands service businesses.

Why lab tests aren't enough: the difference between lab and field

Tools like Lighthouse or PageSpeed Insights are useful for debugging, but they run controlled simulations. Real customers use countless device types, networks and routes to your site. Real User Monitoring (RUM) captures timing data from actual visitors and shows the performance that matters for enquiries and conversions.

Which real-user metrics to track

• LCP (Largest Contentful Paint): how quickly the main content appears to the user.
• INP / Interaction metrics: how responsive the page feels during interactions (replaces older FID guidance).
• TTFB (Time to First Byte): server responsiveness — useful when you change hosting or caching.
• CLS (Cumulative Layout Shift): visual stability — important after layout or image changes.
• Page load / session duration: how long the full page takes to become usable for the typical visitor.

These tell different parts of the visitor experience. When you make changes, compare these metrics for real visitors, not only lab-simulated snapshots.

Practical before & after measurement plan (high-level)

1. Define the test window — collect baseline data for 7–14 days before changes.
2. Segment visitors — separate mobile vs desktop, and Birmingham/West Midlands traffic.
3. Implement the change during a quiet period and document exactly what changed.
4. Collect field data for another 7–14 days after the change.
5. Compare the same segments and look for statistically meaningful shifts in LCP, INP, TTFB and conversions (phone clicks, form submissions).

Why 7–14 days?

A one-day snapshot can be skewed by traffic anomalies. A week captures weekday/weekend behaviour; two weeks is better if your traffic volume is low.

Easy ways to capture real-user performance

Small businesses can choose one of these approaches depending on budget and technical ability:

• Use existing analytics: Many analytics platforms provide field metrics (Google’s field data, analytics dashboards). These are quick to check but may be sampled.
• Inject a simple RUM script: A small JavaScript snippet can collect Performance API timings and send beacons to your server for aggregation. This is lightweight and customisable.
• Custom web app / dashboard: Build a small admin tool that receives beacons, stores events, and shows trends. This is useful for precise before/after comparisons and filtering by city or device.

Practical checklist — Before and After

• Baseline (Before changes)
  • Collect at least 7 days of RUM data for the pages you will change.
  • Segment by device (mobile/desktop) and by location (Birmingham, Solihull, West Midlands).
  • Record current conversion signals (phone clicks, contact form submissions) for the same period.
  • Note server-side metrics (TTFB) from hosting or server logs.
  • Document existing content and resource versions (images, scripts, plugins).
• Implementation
  • Deploy changes in a controlled release and record the timestamp.
  • If possible, change only one major variable at a time (e.g. image optimisation first, then caching).
  • Enable server-side logging to correlate user sessions with server events.
• After changes
  • Collect at least 7 days of RUM data post-release.
  • Compare the same segments and dates of week to avoid bias.
  • Check for regressions: higher CLS, slower INP or increased TTFB.
  • Compare conversion rates and micro-conversions (click-to-call, form opens).
  • Document findings and roll back if a clear negative impact appears.

Short example workflow (practical)

Use this example if you want a repeatable process that includes a small custom web app and AI-assisted triage:

1. Install a tiny RUM script on target pages that records Performance API metrics and the referrer. Make it sample 1–5% of visits if traffic volume is high.
2. Send beacons to a simple endpoint that stores timestamp, page path, device type, city (from IP geolocation) and LCP/INP/TTFB/CLS.
3. Use a small DigiSitio dashboard (custom web app) to aggregate and visualise the metrics. Filter the dashboard to Birmingham and to mobile users.
4. Before changes, export 14 days of baseline metrics from the dashboard.
5. Make the planned change (for example: compress images, add a cache rule or upgrade PHP). Note the deployment time in the dashboard.
6. Collect 14 days of post-change data. Use an AI-assisted tagger (for example, a workflow that classifies slow sessions and groups stack traces) to triage the slowest 5% of sessions — the AI tool can speed up root-cause sorting. A suitable service we use in workflows is https://aiassistsmes.co.uk/.
7. Review the dashboard: compare median and 75th/95th percentiles for LCP and INP, plus changes in conversion signals.
8. Decide on next steps: keep changes, tweak, or roll back and test alternative fixes.

Common before/after traps and how to avoid them

• Compare different audiences: Don’t compare a pre-change week dominated by desktop traffic with a post-change week dominated by mobile traffic. Always use the same segments.
• Seasonality: If you make changes during a local event or promotion, expect behaviour shifts unrelated to performance.
• Large, simultaneous changes: If you change images, CSS and hosting in one release, you won’t know which change caused an improvement or regression. Stagger changes where possible.

When to use a custom web app or an agency

Small tweaks like image compression or caching rules can be handled in-house or by a web developer. If you want reliable segmented RUM, alerting, and correlation with business outcomes (calls, form fills), a low-cost custom dashboard or a short project with a local agency can save time and reduce risk. DigiSitio helps local businesses with measurable performance improvements and custom dashboards — see our blog for related guidance and broader SEO advice at our SEO category and the DigiSitio blog.

For practical, step-by-step performance fixes you can combine measured before/after checks with a concise performance checklist — we cover many of those steps in our checklist post on speeding up slow pages and the image-weight guide: Speed Up Slow Pages and Cut Image Weight, Improve Mobile Responsiveness.

Quick decision guide

• If post-change LCP and INP improve and conversions stay the same or increase: keep the change and monitor.
• If field metrics improve but conversions fall: investigate UX changes, layout shifts or tracking gaps.
• If metrics regress: roll back and test the change in isolation.

Call to action — get a practical performance check for your business

If you run a service business in Birmingham, Solihull, Sutton Coldfield or the West Midlands and want measured before & after checks, we can set up a short RUM pilot, build a dashboard and run a controlled test. Start with a free consultation at DigiSitio and we’ll show a clear plan you can follow and measure.

Want more DIY reading before you call? Check our wider performance and web design guidance on the DigiSitio blog: https://digisitio.com/blog.