# Website Performance Stewardship for Small Businesses > Understand website speed reports, choose useful repairs, and prevent slowdowns with practical tests and agreed performance budgets. Canonical: https://vassalmarketing.com/information/website-stewardship/website-performance-stewardship/ **Maintained by Vassal Marketing** ยท Last updated on September 26, 2026 Reviewed at least quarterly and whenever a platform or rule it cites changes. General information, not legal or professional advice. Check rules that affect your business with a qualified professional. A useful speed review starts with what feels slow: the main content appearing, a menu responding, or a booking form becoming usable. Measure representative pages, find the cause, and check that the repair improves the experience customers actually have. ## Why this matters A page may be quick on your office computer and awkward on a customer's phone. Large images, delayed scripts, moving controls, and outside widgets can affect different parts of the experience. Identify the task and conditions before deciding what needs to change. Field data summarizes real visits, collected by Google from Chrome users. Lab tests run under controlled conditions and help a developer find causes. Both are useful, but they answer different questions. If Google has no real-visitor data for your site, that isn't a failing grade. ## Responsible practices ### Choose pages that represent the business Include a service page, contact page, and any important campaign or booking page alongside the home page. Test realistic images and third-party tools. A repeat visit with cached files can feel different from a first visit, so record which experience you are measuring. ### Explain the important measurements Core Web Vitals are Google's three measures of page experience. Largest Contentful Paint (LCP) is how fast the main content appears. Interaction to Next Paint (INP) is how quickly the page responds to taps and clicks. Cumulative Layout Shift (CLS) is how much the layout jumps. Good targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, met by at least 75% of visits, separately on mobile and desktop. They describe experience; still check the actual task. ### Read the evidence in context Ask whether the report covers one page or the wider site, which devices it represents, and what period it describes. Compare repeated lab runs under the same settings. A lab score recorded today will not instantly replace a field report describing earlier visits. If field data is unavailable, use repeatable tests and representative real-device checks. ### Find the cause before approving a fix The developer should identify what is delaying or shifting the page. A large hero image, slow server response, heavy script, and unstable embed need different repairs. Ask for a plain explanation of the bottleneck, the proposed change, and the customer task that should improve. ### Keep future additions within an agreed budget A performance budget is a set of limits or targets used to catch a slower release. It might cover image size, script weight, or a measured interaction. Agree the targets with your provider and review new widgets, video, fonts, and tracking against them. Verify that speed changes preserve accessibility, content, privacy controls, and working forms. ## Worked example: Reading a slow service-page report Hypothetical example: a mobile test finds that the main image appears late. There is not enough page-level field data to describe real visitors reliably. ### What the report tells you The controlled test found a loading problem under its stated conditions. It does not tell you that every visitor waits the same amount of time. ### What to investigate Ask the developer to check when the image is discovered, how large it is, and whether other work delays its display. The metric identifies the symptom; the trace helps locate the cause. ### What to approve Agree on the smallest useful repair, such as an appropriately sized image or corrected loading priority, once the diagnosis supports it. ### What to compare Repeat the same tests, inspect image quality and layout, and complete the inquiry path. Keep a record of the released version so later results can be compared fairly. A useful report connects an observed delay to a repair and a retest. It should also state what the available data cannot establish. ## Page speed checklist ### What you can check 1. Note the page, device, and task when something feels slow. 2. Choose a small set of important pages for regular comparison. 3. Ask the provider to explain the first proposed repair and how it will be measured. 4. Review the cost of new widgets or media before adding them to every page. ### What to ask your provider to handle 1. Separate field data from lab tests and record the pages, devices, test settings, and comparison period. 2. Use browser performance traces to find the cause, then retest under the same conditions. 3. Apply agreed performance budgets and watch for regressions after content, software, or third-party changes. ## Avoid these failures - Comparing results from different devices, dates, pages, or test conditions as though they were identical. - Removing useful content or necessary controls merely to improve a score. - Adding a heavy widget to every page without checking its cost or purpose. Good website care lowers risk, but no provider can guarantee uninterrupted service. ## Questions business owners ask ### What do LCP, INP, and CLS mean? LCP describes when the main content appears, INP describes responsiveness to interaction, and CLS measures unexpected visual movement. Use them with checks of the task a customer is trying to complete. ### Why do the field report and lab score disagree? They represent different conditions and samples. Field data summarizes actual visits over a period; a lab run uses controlled settings. Check the URL scope, device, dates, and test configuration before comparing them. ### What if the site has no field data? Small sites often have too few visits for Google to report real-visitor data. That isn't a failing grade. Use repeatable lab tests and checks on real phones instead. ### Should every page get a perfect score? No. Prioritize the tasks customers complete and the causes of a poor experience. A perfect lab score is not the goal, and chasing it should not break important content or functions. ## Primary guidance - [web.dev: Web Vitals](https://web.dev/articles/vitals) - [web.dev: Core Web Vitals workflows with Google tools](https://web.dev/articles/vitals-tools) - [Chrome for Developers: View CrUX data in PageSpeed Insights](https://developer.chrome.com/docs/crux/guides/pagespeed-insights) - [MDN Web Docs: Performance budgets](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Performance_budgets) ## Connected guidance - [Technical SEO](https://vassalmarketing.com/information/technical-seo.md): Understand speed, crawling, and the other technical checks search engines rely on. - [Paid search landing pages](https://vassalmarketing.com/information/paid-search/paid-search-landing-pages.md): Make sure ad visitors land on fast, clear pages that lead to a call or form. - [Ongoing website maintenance](https://vassalmarketing.com/information/website-stewardship/ongoing-website-maintenance.md): Agree on routine care, urgent response, and a report you can understand. - [Small-business website accessibility](https://vassalmarketing.com/information/website-stewardship/small-business-website-accessibility.md): Find barriers in important tasks and coordinate checks and repairs with your provider.