# Reading LCP, INP and CLS as a business owner LCP concerns main-content loading, INP interaction responsiveness and CLS unexpected layout movement. Interpret these measures with the device, connection and data source in view. A fast laboratory run does not show how all real customers experience a page on older phones or slower connections. Do not advertise laboratory scores as proof of real-user performance or guaranteed business results. ## Read the report as three different questions Imagine a visitor opening your services page on a midrange phone. The main photograph takes time to appear, the menu responds late, and a banner moves the contact button just before it is pressed. These are different problems. A single overall score can conceal that distinction, so ask your developer to identify which experience each proposed change addresses. LCP concerns the appearance of the largest relevant content; INP concerns response to interactions; CLS concerns unexpected movement. Google's [Web Vitals guidance](https://web.dev/articles/vitals) explains the metrics and the distinction between field and laboratory measurement. Use the names to organise a conversation, rather than treating them as a certificate that every visitor had a good experience. Write a small observation beside the number: “main image appears late,” “filter stalls after typing,” or “heading moves when the font arrives.” This makes the report actionable for a business owner. An improvement should connect an observed problem, a plausible cause and a change that can be checked. A percentage without that explanation gives you little basis for deciding what work to fund. ## Compare like with like before approving work Ask for the tested address, date, device profile and connection settings. A fast result on a developer's laptop is not directly comparable with a throttled mobile run. Compare the same page under the same conditions before and after a change, and keep more than one run when results vary. A screenshot of the score alone is an incomplete handover record. For example, a portfolio may have a fast homepage but slow project pages because each project includes many large photographs. Testing only the homepage would miss the actual browsing experience. Choose representative pages: the busiest landing page, one image-heavy detail page and the application form. Try a menu, a language change and a validation error as well as the initial load. A new site may not have enough real-user data for a meaningful field report. Record that as unavailable, not as zero delay or a pass. Lab checks remain useful for finding problems, but they cannot establish that all real customers experience the same speed. Equally, one unusually slow personal connection should trigger investigation rather than an immediate conclusion about every visitor. ## Prioritise changes by the experience they repair Start with conspicuous issues: oversized main images, unnecessary scripts before useful content, missing image dimensions or expensive work triggered by small interactions. Ask what can be removed before paying to optimise a feature that provides little value. A decorative video that blocks the service explanation may simply be the wrong design choice. Use a short acceptance note for each change. An image fix might require a suitable mobile source and an unchanged visual composition. A menu fix should preserve keyboard operation while responding promptly. A layout fix should reserve space without leaving an awkward blank area. This prevents a better number from becoming a worse page. Keep the original and revised reports alongside the deployment date. If another tool is added later, repeat the relevant checks. Performance is a maintained property of the experience, not a permanent badge earned during launch. For a small business, understandable content and a dependable application journey remain the purpose of the technical work. **An owner-friendly acceptance example.** Suppose the proposed repair is to replace a heavy hero photograph. Ask to see the original and revised page with the same heading and screen size. Confirm that the subject remains visible, the text does not lose contrast and the browser uses a sensibly sized image on mobile. The report should describe the change and the observed effect without presenting it as a promised sales increase. For interaction work, use the action that actually felt delayed. Open and close the menu, change a filter or correct a form field several times. Watch for lost input, focus moving unexpectedly and duplicate actions. A page that reacts faster but submits twice has not improved the whole experience. Keep the acceptance decision tied to the user's task. Ask the supplier to separate measured values, proposed targets and unavailable evidence in the handover. This distinction remains useful when a later tool or content change requires another review. It also prevents a launch-time laboratory result from being reused indefinitely as a claim about real visitors. ## Practical checklist - Distinguish lab and field data - Record the tested page - Compare consistent conditions **A concrete example:** A fast laboratory run does not show how all real customers experience a page on older phones or slower connections. **A boundary to keep clear:** Do not advertise laboratory scores as proof of real-user performance or guaranteed business results. ## Your next step [Tell Orvunweb about your project](/en/start-a-project/) ## Related reading - [How to check whether a website is mobile friendly](/en/blog/how-to-check-whether-a-website-is-mobile-friendly/) - [Common choices that slow down websites](/en/blog/common-choices-that-slow-down-websites/) - [Separating bot traffic, visitors and enquiries](/en/blog/separating-bot-traffic-visitors-and-enquiries/) - [Business website service](/en/services/business-website/) - [Compare packages](/en/pricing/) ## Related services - [Business website](/en/services/business-website/) --- Locale: en Canonical: https://orvunweb.com/en/blog/reading-lcp-inp-and-cls-as-a-business-owner/ Updated: 2026-09-16 - [web.dev — Web Vitals](https://web.dev/articles/vitals)