Core Web Vitals Audit Service: A 30-Day Business Plan for Indian Freelancers

A small ecommerce brand spends money bringing customers to its website, but the product pages feel slow on mid-range phones. The owner runs a free speed test, sees a list of technical warnings and does not know which problems matter. This creates an opportunity for a freelancer who can turn website performance data into a clear, tested action plan. A Core Web Vitals audit service helps businesses understand how quickly key content appears, how responsive pages feel and whether elements move unexpectedly while users interact. The service is not just a screenshot of a performance score. Its value comes from selecting important pages, comparing real-user evidence with controlled tests, identifying likely causes and giving the client's developer a prioritised set of fixes. This guide explains the technical basics, a defined service offer, sample economics, safe client access, delivery templates and a 30-day launch plan for Indian freelancers and small agencies. It is a business idea, not a promise of immediate search ranking or sales growth. What are Core Web Vitals? Google's PageSpeed Insights documentation identifies three Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). They measure different parts of the user experience. For real-user data, Google generally evaluates the 75th percentile, meaning the value at or below which 75% of observed experiences fall. MetricWhat it measuresGood thresholdTypical issue LCPWhen the largest visible content element renders2.5 seconds or lessHeavy hero image, slow server, render-blocking resources INPResponsiveness to user interactions200 milliseconds or lessLong JavaScript tasks, heavy third-party scripts CLSUnexpected visual movement0.1 or lessImages without reserved dimensions, injected banners, shifting fonts The thresholds are guidance for the measured experience, not guaranteed conversion targets. For example, an LCP of 3.2 seconds falls in the needs-improvement range. An INP of 620 milliseconds is poor. A CLS value of 0.08 is good. Google classifies a Core Web Vitals assessment as passing when the available qualifying field metrics meet the relevant good thresholds under its documented rules. Why a free tool does not eliminate the service opportunity Anyone can run PageSpeed Insights. A business owner still has to decide what to fix, whether the problem affects important visitors, which developer should own it and how to verify improvement. One page may show a low lab score while real-user field data looks acceptable. Another page may pass a desktop test and struggle on mobile networks. Google explains that PageSpeed Insights combines controlled laboratory diagnostics with real-user data from the Chrome User Experience Report, or CrUX. Field data typically reflects a trailing 28-day window. Lab tests are useful for debugging, while field data reflects actual experiences across devices and networks. These are complementary signals, not interchangeable scores. For a small business, the deliverable should answer: Which pages are affected? Which metric is failing? What evidence supports the finding? What should the developer do first? How much effort might the fix require? How will we confirm that the problem improved? Choose a narrow customer segment Start with a segment where page speed affects a meaningful workflow. Candidates include ecommerce stores, lead-generation websites, appointment booking pages, course businesses and B2B product catalogues. A freelancer with experience in Shopify or WordPress may have an advantage because the likely causes and implementation constraints repeat across clients. Do not begin by claiming you can audit every technology stack. A static brochure site, a JavaScript-heavy web application and a large marketplace can require different skills. A narrow first offer might be a five-page mobile performance audit for WordPress service businesses or a product-page performance review for small Shopify stores. Define the exact audit deliverables Offer a written report that includes the tested URLs, test date, device context, field-data availability, metric values, key screenshots, likely causes, a ranked fix list and a 30-minute handoff call. Include a plain-English executive summary for the founder and a technical appendix for the developer. State what is excluded: code changes, hosting migration, plugin purchases, conversion guarantees and unlimited retesting. DeliverableClient receivesWhy it matters Page inventorySelected homepage, category, product, form or landing pagesPrevents a homepage-only diagnosis Baseline measurementsField metrics where available and repeated lab runsSeparates user experience from test noise Root-cause hypothesesEvidence tied to images, scripts, fonts or server behaviourMakes findings actionable Prioritised backlogIssue, impact, effort, owner and validation methodHelps the client choose work Handoff and retest planDeveloper discussion and post-fix checksReduces misunderstanding A practical six-step audit workflow Step 1: Agree on scope and permissions Ask the client which pages generate leads or orders, what devices their visitors use and whether recent changes affected performance. Request read-only access to analytics or Search Console only when needed. Public PageSpeed checks usually do not require credentials. Never request passwords through chat or copy private customer data into external tools. Step 2: Capture field data before running lab tests Check the Core Web Vitals report in Search Console when the client grants access, and review PageSpeed Insights for selected URLs. Record whether field data is URL-level, origin-level or unavailable. A low-traffic page may not have enough CrUX samples. In that case, say so explicitly rather than inventing a pass or fail. The official CrUX API documentation explains its percentiles and distribution data. Field metrics represent anonymised real-user experiences, not a test performed on your own computer. They can lag recent fixes because they cover a rolling observation period. Step 3: Run controlled tests more than once Use Lighthouse through PageSpeed Insights or browser developer tools. Record mobile and desktop results separately. Repeat tests under consistent conditions, because network, server and device variability can change scores. Look at the diagnostic details rather than optimising only the overall score. For example, if the main product image is the LCP element, inspect its size, format, loading priority and delivery path. If interaction responsiveness is poor, examine long tasks and third-party scripts. If a page shifts while loading, check image dimensions, ad slots, banners and font behaviour. Do not assume that one recommendation fixes every page. Step 4: Build an evidence-based issue list For each issue, include the page, observed metric, likely cause, supporting screenshot or trace, recommended change and expected validation test. Separate confirmed findings from hypotheses. If the problem appears only in a simulated test and not in available field data, explain that distinction. Use a simple priority rule: high user impact plus high confidence plus manageable effort should be reviewed first. A slow checkout page may deserve more attention than a rarely visited legal page, but the client's traffic and revenue data should determine the final order. Step 5: Review fixes with the developer A useful auditor does not send a vague instruction to 'improve page speed'. Explain which image should be resized, which script may be delayed, which font needs loading changes or which server response requires investigation. Let the developer confirm feasibility and possible side effects. Changing a caching rule can affect logged-in users, carts or dynamic content, so implementation requires testing. Step 6: Validate without promising instant field-data changes After fixes, rerun comparable lab tests and inspect the affected pages manually. Record before-and-after evidence. If CrUX data is available, monitor its rolling window over time. Do not claim that a one-day Lighthouse improvement proves that every real user now has a good experience. A sample audit finding a client can act on FieldIllustrative finding PageProduct detail page ProblemLab LCP of 4.3 seconds on tested mobile profile EvidenceLarge above-the-fold image loads late in the waterfall HypothesisImage size and loading priority contribute to delay Suggested actionTest appropriate image dimensions, compression and priority OwnerWebsite developer ValidationRepeat comparable lab runs and monitor field data ConfidenceMedium until the developer tests the change The example numbers are invented for teaching. They are not results from a real client site. The format matters because it prevents the auditor from turning an observation into an unsupported promise. How much could you charge for a Core Web Vitals audit? Price based on work and client value, not a claim that every audit in India costs the same amount. As illustrative starting packages, a freelancer could test a small three-page site for ₹5,000, offer a deeper five-to-eight-page audit for ₹12,000, or quote a larger custom engagement after scoping. These are business-model examples, not verified market averages. Suppose a five-page audit sells for ₹12,000. You spend six hours on testing and analysis, two hours on the report and one hour on client discussion. At an internal delivery cost of ₹500 per hour, direct labour is ₹4,500. Add ₹700 of allocated tools and project expenses. Direct cost is ₹5,200 and contribution before overhead and tax is ₹6,800, or about 56.7% of revenue. If the same audit takes 15 hours instead of nine, labour rises to ₹7,500 and direct cost to ₹8,200. Contribution falls to ₹3,800. The lesson is to limit the number of pages, reports and revisions in the package, and to track actual effort. Nitross's productized services guide explains how to create repeatable packages without hiding the work involved. Where to find your first clients Choose a niche and review public websites without intrusive scanning. Identify a visible issue on a public page, then send a short message explaining what you observed and what remains unverified. Avoid claiming you audited the entire business from a single score. Offer a defined paid diagnostic rather than a free full report. Potential channels include existing web design clients, local ecommerce agencies, WordPress maintenance providers, Shopify developers and businesses running paid campaigns to slow landing pages. A referral partnership with a developer can work if responsibilities are clear: the auditor identifies and validates problems; the developer quotes and implements fixes. Build two or three demonstration reports on your own website or sites you have permission to test. Show the audit method and how you prioritise findings. Do not use a third-party company's logo or private analytics without consent. A good sample report is more persuasive than a claim of guaranteed Google rankings. Why ranking guarantees are a bad sales promise Google recommends good Core Web Vitals for user experience, but explicitly states that strong scores do not guarantee good search rankings. Search results depend on many factors, including content relevance and quality. A performance audit can help identify technical friction. It cannot isolate or guarantee its effect on search traffic or sales. Offer measurable deliverables that you control: baseline capture, diagnostic quality, a clear fix backlog, technical handoff and retest evidence. If the client also wants a broader website review, you can explain how this differs from Nitross's accessibility audit service guide and localization QA service guide. Those services test different problems and should not be presented as identical. A 30-day launch plan Days 1 to 5: Learn LCP, INP and CLS using official documentation. Practice reading field and lab data. Create a glossary explaining each metric in simple language and build a sample issue log. Days 6 to 10: Audit two sites you own or have permission to assess. Compare mobile and desktop, record data availability and write concise findings. Ask a developer to challenge your proposed fixes. Days 11 to 15: Choose one customer niche. Define page limits, report format, turnaround, revision policy, access requirements and price. Prepare a one-page offer and sample report with clearly labelled illustrative data. Days 16 to 22: Contact 20 relevant prospects or partners. Personalise each message with one publicly observable issue and a clear explanation of what a paid audit would add. Record replies, objections and discovery calls. Days 23 to 30: Deliver a pilot engagement with written consent, collect feedback and compare estimated versus actual hours. Refine your checklist, technical handoff and pricing. Only then consider adding implementation or ongoing monitoring services. Common mistakes to avoid Using one Lighthouse run as proof of real-user performance. Confusing URL-level and origin-level field data. Promising guaranteed rankings, conversion rates or a permanent score of 100. Ignoring mobile conditions while reporting only desktop performance. Providing generic recommendations without page-level evidence. Accessing client accounts or copying data without clear permission. Offering unlimited retests in a fixed-price package. Claiming a technical fix is complete without a developer validation step. Frequently asked questions Can I start this service without being a developer? You can learn measurement and reporting, but credible root-cause analysis requires technical understanding. Start with a narrow diagnostic service and partner with a developer for findings that require code-level investigation. Do not promise fixes you cannot validate. Are Core Web Vitals the same as the PageSpeed performance score? No. Core Web Vitals are LCP, INP and CLS. The Lighthouse performance score is a lab-based composite and may change between runs. Field data and lab scores answer different questions. What if a site has no field data? Report that field data is unavailable. Use controlled lab tests for diagnostics and explain the limitation. Do not manufacture real-user metrics or infer a passing assessment. How long does it take to show improvement? Lab tests may show a change immediately after deployment. Field data generally uses a rolling 28-day window, so changes may take time to appear. Results also depend on real traffic and device conditions. Should I include implementation in the audit price? Not by default. Separate diagnosis from implementation unless you have the skills, access and a defined scope. This protects the client from unclear promises and helps you estimate work accurately. Your next action Pick one website you own or have permission to test. Measure three important pages on mobile, record LCP, INP and CLS field-data availability, run repeatable lab diagnostics and write one evidence-backed fix recommendation for each page. Turn that work into a sample report before offering the service to paying clients. Primary references: Google PageSpeed Insights documentation; Chrome UX Report API documentation; Google Search Central page experience guidance. Technical guidance checked 30 October 2026.