Substantively updated October 9, 2026. Original publication date retained.
A useful website optimization plan starts with a specific problem: a service page loads slowly, the layout jumps while someone reads, or an inquiry form fails on a phone. Measure that problem, fix the likely cause, and check whether the change helped.
For a small business, we would begin with the pages customers use to evaluate a service and contact you. A faster homepage is useful, but it will not fix a broken quote form.
Establish a baseline
Choose a few representative pages: homepage, main service page, a project or article, and contact page. Record the date, URL, device, and test conditions. Save the findings before changing anything.
PageSpeed Insights combines lab diagnostics with real-user data when enough eligible data is available. Lab testing helps investigate a page under controlled conditions; field data reflects actual visits. A missing field-data report does not mean the page passed or failed. Read how PageSpeed Insights works.
Also use the site on a phone. Open the menu, follow the service links, complete the form, and confirm the message arrives. Record usability failures alongside performance findings.
Understand the current Core Web Vitals
The current measures are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. INP replaced First Input Delay as a Core Web Vital in 2024.
| Metric | What it describes | Good threshold |
|---|---|---|
| LCP | How soon the largest visible content element is rendered | 2.5 seconds or less |
| INP | Responsiveness to user interactions | 200 milliseconds or less |
| CLS | Unexpected layout movement | 0.1 or less |
These targets apply at the 75th percentile of visits, assessed separately for mobile and desktop. A standard Lighthouse page-load test cannot measure real-user INP; its Total Blocking Time diagnostic can help investigate related responsiveness problems. See Google’s Web Vitals definitions and measurement guidance.
Use scores to identify problems, not as a sales forecast. Good Core Web Vitals do not guarantee top search rankings. Google explains their role in Search.
Choose the next fix from the evidence
| Observed problem | What to investigate | How to check the change |
|---|---|---|
| Main image appears late | Image size, discovery, loading priority, server response | Repeat the same lab test and inspect the loading sequence |
| Page jumps while loading | Missing image dimensions, embeds, fonts, late content | Watch the affected layout and inspect shift diagnostics |
| Menu or form feels unresponsive | Long JavaScript tasks and third-party scripts | Test the actual interaction and review responsiveness data |
| Form submissions do not reach you | Validation, delivery service, spam filtering, notification setup | Submit successful and invalid test requests |
| Visitors cannot find the relevant service | Navigation, headings, service descriptions | Ask someone unfamiliar with the site to complete a realistic task |
These are investigation paths, not promises that a particular upgrade will solve every symptom. Assign each confirmed problem an owner, expected benefit, and verification step.
Make images fit their job
A project photo needs enough detail to show the work, but it should not require every phone to download the largest source file. Provide appropriately sized variants and let the browser choose through responsive image markup. See responsive image guidance.
Compare formats and compression settings on your actual images. Keep originals separately and inspect the output for lost detail, broken transparency, or unreadable text. There is no fixed percentage reduction that applies to every JPEG, PNG, WebP, or AVIF conversion.
Reserve space with image dimensions. Lazy-load images that are off screen, but avoid lazy-loading the main image visible when the page first opens: delaying it can hurt loading performance. Read Google’s browser image-loading guidance.
For example, on a contractor’s project page, we would prioritize the first useful project image and defer the later gallery photos. We would then check the page on a narrow screen and confirm that the gallery still works.
Review scripts, caching, and hosting carefully
Make an inventory of chat, advertising, analytics, maps, video, and booking integrations. Identify which ones support a real business task. Test the effect of changing one integration at a time; removing an unused widget may be simpler than rebuilding the site.
Ask your developer to inspect network requests, compression, and caching before buying a larger hosting plan. A slow third-party embed may not improve when your own server gets more resources.
Caching also needs correct boundaries. Public images and personalized account pages have different requirements. Have the person responsible for the application verify that private responses are not shared between users, and that changed content can be refreshed reliably.
An app installation prompt or offline mode is not a routine requirement for a local service website. Add those features when there is a clear customer need and someone can maintain them.
Check content and the inquiry path
Read an important service page as a prospective customer. Does it explain what work you accept, where you operate, and how to request an estimate? Do links and buttons describe their destination?
Keep form fields tied to the information needed to respond. Show understandable error messages and a clear success message. Test keyboard navigation, phone-sized screens, and failed submissions as well as successful ones.
Track a successful inquiry separately from a button click. Analytics can help describe behavior, but confirm actual inquiries and booked work in your business records. Avoid treating a change in visits as proof of more customers.
Review results without overclaiming
After a change, repeat the same tests. Compare field data only after enough new visits have been collected, and note changes in advertising, seasonality, content, and measurement setup.
A practical monthly record can contain the affected URL, the problem, what changed, the test result, and any remaining limitation. For example: “Reduced the project image dimensions; repeated mobile tests show earlier image rendering; inquiry counts are too small to assess a business effect.” That is a hypothetical reporting example, not a client result.
Start with the broken customer task or the largest verified performance obstacle. A focused, measured improvement is easier to evaluate and maintain than a long list of upgrades with no baseline.