Quick answer
A performance audit should measure real user experience with field data such as Core Web Vitals, test key pages and journeys in the lab, separate front-end, server, database and third-party delays, identify the largest bottlenecks, fix them in order of impact and set up monitoring to prevent regression. Optimize based on measurement, not assumptions.
Key takeaways
- Start with real user data, not only a single lab test.
- Separate front-end, back-end, database and third-party causes.
- Fix the largest bottlenecks first and measure each change.
- Add performance budgets and monitoring to prevent regression.
Who this guide is for
Website owners, product managers and developers whose website or web application feels slow to users.
Define slow with data
Gather field data from real users: Core Web Vitals in Google Search Console or the Chrome UX Report for public sites, and real user monitoring or analytics for applications. Identify which pages, devices, locations and actions are slow. Complaints often concern specific journeys such as search, checkout or report generation rather than the whole site. Agree target metrics before starting so improvements can be judged objectively.
Measure Core Web Vitals for public pages
Core Web Vitals focus on loading, responsiveness and visual stability: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google’s published thresholds for a good experience are LCP within 2.5 seconds, INP within 200 milliseconds and CLS below 0.1, measured at the 75th percentile of page loads. These metrics affect user experience and are among the signals Google uses in search, so they matter for both conversions and visibility.
Analyse front-end weight
Use lab tools such as Lighthouse and browser developer tools to examine page weight, render-blocking resources, large images, unused JavaScript and CSS, and fonts. Common fixes include properly sized and modern-format images, lazy loading below-the-fold content, code splitting, removing unused libraries and preloading critical resources. Single-page applications often ship large JavaScript bundles that delay interaction on mid-range phones.
Check server and database time
Measure time to first byte and server response times for key endpoints. Use application performance monitoring to find slow requests and database queries. Missing indexes, queries inside loops, unbounded result sets and heavy reports run on the main database are frequent culprits. Caching, query optimization and moving heavy work to background jobs often deliver large improvements without changing infrastructure size.
Audit third-party scripts
Chat widgets, analytics, tag managers, ad scripts, heatmaps and embedded videos can add substantial delay and block interaction. List every third-party script, its purpose and owner, and measure its cost. Remove unused ones, load others after main content or on interaction, and use lightweight alternatives where possible. Marketing tools are often added over time without anyone measuring their combined effect.
Consider network and hosting
Users far from your server experience higher latency. A content delivery network caches static assets and sometimes pages closer to users. Check hosting resources, HTTP/2 or HTTP/3 support, compression and caching headers. Scaling server size helps only when the server is actually the bottleneck; otherwise it adds cost without improving experience.
Prioritize fixes and prevent regression
Rank findings by impact on the slow journeys and effort to fix. Implement and measure one change at a time where possible. Set performance budgets, such as maximum bundle size or LCP target, and add checks to the release pipeline. Continue monitoring field data, since lab improvements need confirmation from real users, which takes time to reflect in aggregated reports.
Scope checklist
- Which pages and journeys are slow for real users?
- What are current Core Web Vitals at the 75th percentile?
- How much time is server versus front-end?
- Which third-party scripts load on key pages?
- Is performance monitored after releases?
Frequently asked questions
What are good Core Web Vitals scores?
Google’s good thresholds are Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds and Cumulative Layout Shift below 0.1, at the 75th percentile.
Does website speed affect SEO?
Page experience, including Core Web Vitals, is among the signals Google uses, though content relevance matters more. Speed strongly affects user experience and conversions.
Will a bigger server make my website faster?
Only if the server is the bottleneck. Many slow sites are limited by front-end weight, third-party scripts or inefficient database queries.
Sources and implementation references
- web.dev: Web Vitals
Definitions and thresholds for Core Web Vitals.
- Google Search Central: Core Web Vitals and Search
How Google Search uses Core Web Vitals.
Prepared with AI assistance as an engineering decision guide. Examples are illustrative unless explicitly labelled as an internal implementation. No independent expert review or customer outcome is claimed.
Need help investigating this issue?
Describe what is failing and which platform you use. Do not submit passwords, API keys, or confidential customer data. Scope, access, dependencies and commercial terms are agreed before delivery. Do not submit passwords, API keys or confidential records.
