A PageSpeed score is a diagnostic result, not a verdict on your insurance agency. The important questions are whether visitors can see the main content, use the page without delays or unexpected movement, and reach the office successfully.
Core Web Vitals describe loading, responsiveness and visual stability. PageSpeed Insights combines different kinds of evidence that can legitimately disagree. Download the speed audit worksheet to keep those distinctions clear when reviewing a developer's recommendations.
For contact links and search settings alongside performance, see the 50-state website audit.
Start with the three Core Web Vitals
Google's Web Vitals guidance defines the current measures and good thresholds:
| Metric | Visitor experience | Good threshold |
|---|---|---|
| Largest Contentful Paint, LCP | Main visible content appears | 2.5 seconds or less |
| Interaction to Next Paint, INP | Page responds to interaction | 200 milliseconds or less |
| Cumulative Layout Shift, CLS | Content stays in place | 0.1 or less |
Assess the 75th percentile, with mobile and desktop considered separately. A passing assessment requires the applicable good thresholds across the Core Web Vitals. Record the actual report's scope and availability rather than turning a missing measurement into a pass.
These are experience measures, not agency sales benchmarks. A page can meet the thresholds and still explain the wrong product, route calls incorrectly or fail to save a form.
Separate field data from a lab test
Read the evidence before chasing the score
- Field experience
What eligible real visitors experienced over the reported period.
Record URL or origin scope and device class. - Lab diagnosis
A controlled page load that helps locate technical problems.
Record tool version, settings and run date. - Journey verification
Can a visitor use navigation, call and complete the contact path?
Test interactions beyond the initial page load. - Business review
Do useful inquiries arrive and reach the office?
Speed metrics alone do not establish conversion lift.
Field data describes actual eligible user experiences in the reported collection period. Lab data describes a controlled test under specified conditions. The former helps identify what users experienced; the latter helps diagnose and verify changes.
Google's PageSpeed Insights documentation explains the distinction. Check whether the real-user section describes the tested URL or the broader origin. An origin result is not proof that every page has identical performance.
A fresh laboratory run can improve immediately after a repair while the field report still includes earlier visits. Device capability, network, geography, caching and interactions can also differ. Record the field period and test date before declaring a contradiction.
If there is insufficient public field data, write “not available.” It does not mean the site is good, poor, unused or unindexed. Use repeatable lab tests and, where appropriate, permission-conscious real-user monitoring to investigate further.
Do not mistake a performance score for the whole experience
A Lighthouse performance score combines selected lab metrics. It can move between runs because test conditions and page behavior vary. Compare repeated tests using the same configuration rather than celebrating a single unusually high result.
A normal navigation-only Lighthouse run does not measure real-user INP. Total Blocking Time can help diagnose responsiveness issues, but it is not an interchangeable INP result. Test the actual menu, form and other interactive controls.
The accessibility and SEO scores also have limited scopes. A high automated accessibility score does not replace keyboard and human usability checks. An SEO score does not establish rankings, coverage or useful content.
Choose representative pages and paths
Test the homepage, a major service page, a contact page and an office page if applicable. Include paid landing pages and a long article if they use different templates. A fast homepage does not prove every embedded quote workflow works well.
For each page, record the URL, final redirected URL, date, mobile or desktop setting, tool, field scope and report link or saved output. Record unavailable results and errors as separate states.
Then use the page. Open navigation, activate the phone link, complete a controlled form and inspect errors. Include the transition to any external carrier or quoting system, while documenting where the agency's measurement stops.
Fix slow main content by identifying the actual LCP element
Match the symptom to the next investigation
- Slow main content
Inspect server delay, resource discovery and the actual LCP element.
Avoid lazy-loading the main visible image. - Delayed interactions
Inspect long tasks and expensive event handlers.
Test the menu and form on a constrained device. - Moving layout
Inspect unsized media, inserted content and font changes.
Reserve space before content arrives.
The main content may be an image or a text block. Ask the developer to identify the measured element and its delay before recommending a new hosting plan.
Google's LCP optimization guide breaks the path into server response, resource discovery, resource loading and rendering. A smaller image will not solve every delay if the browser discovers it late or waits for script execution before displaying it.
Common investigations include an oversized hero image, hidden resource discovery behind JavaScript, unnecessary redirects and slow server work. The appropriate repair depends on the trace.
Use responsive image sizes and an appropriate format. Avoid lazy-loading the important opening image. Give media dimensions or a stable aspect ratio. Keep agency photography visually useful; reducing every image to an unattractive blur is not a design solution.
Investigate delayed menus and forms as responsiveness problems
A page can load quickly and still react slowly after a visitor taps the menu. Expensive JavaScript, long tasks and excessive rendering can delay useful feedback.
Google's INP optimization guidance focuses on the work around interactions. Ask for evidence from the interaction that feels slow. Review unnecessary JavaScript, large tasks and costly updates instead of assuming the initial network transfer explains everything.
Insurance sites often include call tracking, chat, review widgets, maps and quote embeds. Inventory each script's owner and purpose. Remove unused tools; load necessary tools appropriately. Verify the contact path after every relevant change so an optimization does not silently disable routing or attribution.
The marketing-site architecture guide explains why public content does not always need application-level complexity.
Prevent the page from moving under the visitor
Unexpected movement can push a button away just as someone taps it. Investigate unsized images, late banners, embedded widgets and font changes. Reserve the necessary space before content arrives where practical.
Test form errors and confirmations as well as page load. A large error block inserted above the submit button can create a confusing experience even when the initial report looks good. Keep field labels, errors and focus behavior predictable.
Do not remove useful disclosures merely to improve a score. Improve their placement and loading behavior while preserving the information the visitor needs.
Prioritize repairs by evidence and consequence
| Finding | Priority logic | Acceptance evidence |
|---|---|---|
| Form or phone path fails | Repair the contact failure first | Controlled end-to-end verification |
| Main service content appears late | Investigate the measured loading bottleneck | Comparable repeated lab runs and later field evidence |
| Menu or form feels unresponsive | Profile the actual interaction | Interaction works on representative devices |
| CTA shifts unexpectedly | Identify the source of movement | Stable layout through relevant states |
| Unused third-party script | Remove after confirming no dependency | No functional regression and reduced unnecessary work |
| Small score fluctuation without a clear problem | Observe before rebuilding | Consistent test method and a reproducible finding |
Consider how many important pages are affected, how often the problem occurs and the risk of the proposed change.
A platform migration should solve a demonstrated constraint. Our WordPress versus Next.js comparison discusses maintenance and delivery choices. Neither framework name guarantees a fast or effective website.
Verify the repair
Save a before report, the specific change and comparable after reports. Keep the same test configuration so the results can be compared.
Monitor field data as new visits enter the reporting period. Keep device classes and URL/origin scope consistent. If own-site real-user monitoring is used, collect only appropriate performance information and avoid exposing contact data or sensitive URL parameters.
Review the conversion guide separately. Better loading can support usability, but sales depend on the offer, traffic, intake and office response.
What to ask a speed provider
Ask which page and experience is failing, what evidence supports the diagnosis, which changes are included and how functionality will be retested. Request the original reports, not only a cropped score badge.
Clarify ongoing responsibilities. New images, scripts and embeds can change performance after the initial repair. Review website and care pricing and the exact agreed scope. A one-time high score is not a maintenance plan.
If a provider proposes a rebuild, use the redesign decision checklist to compare a focused repair with replacement. Discuss the website scope with the affected URLs and saved reports.
Common questions
Why does PageSpeed show 100 while Core Web Vitals fail?
The score and the field assessment use different evidence. Check device, reporting period and URL versus origin scope. A controlled run can look good while real users experienced slower or more unstable pages.
Does every agency need a 100 score?
No universal business requirement follows from that number. Prioritize good real-user experience, reproducible problems and functioning customer journeys. A perfect lab score does not guarantee rankings or inquiries.
Is no field data the same as failing?
No. It means the public report lacks sufficient eligible data for that scope. Keep it separate from pass and fail, and use other appropriately labeled evidence.
Can we measure the whole site from the homepage?
No. Review representative templates and important journeys. External quoting tools, office pages and contact forms may behave differently from the homepage.