You can sell a useful website speed audit without promising rankings or pretending one test tells the whole story. The beginner-friendly offer is a fixed-scope review: measure a small business site, document the largest problems, explain what each problem costs the visitor, and deliver a prioritized fix list. AI can help organize findings and draft plain-English explanations, but the measurements and recommendations still need human verification.
This is a better starting service than a vague “AI optimization” package. The client can see what you checked, what you found, and what to do next. You can also run the work with free public tools before paying for a monitoring platform.
What a website speed audit actually includes
A small audit should answer four questions:
- How does the page behave on a realistic mobile connection?
- Which files, scripts, fonts, or layout choices are slowing it down?
- Which fixes are safe for this site and which need a developer?
- How will the client verify that a change helped?
Chrome’s official Lighthouse documentation explains that the tool can audit performance, accessibility, best practices, and SEO from DevTools, PageSpeed Insights, or the command line. Those lab audits are useful, but they are not the same as field data from real visitors. Google’s Core Web Vitals guidance recommends evaluating real-user performance at the 75th percentile, with “good” thresholds of 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift.
That distinction belongs in every client report. A single clean lab run is evidence about one controlled session. It is not proof that every visitor gets the same experience, and it is not a guarantee of better search rankings or more sales.
My dated test on a public WordPress page
I ran a browser-based test on the public AI Hustle Path homepage on July 18, 2026. I used a 390-by-844 mobile viewport in Chromium and captured both the visible page and the browser’s Navigation Timing and Paint Timing entries. The browser reported a complete navigation in about 1,469 milliseconds and a First Contentful Paint entry at 1,736 milliseconds. The captured HTML response showed a transfer size of about 48.7 KB and a decoded size of about 242.4 KB.
These figures are a repeatable observation from one browser session, not a Core Web Vitals field report. The browser identified the connection as effective 4G with a reported 1.6 Mbps downlink and 100 ms round-trip time, but emulated or browser-reported network conditions are not a substitute for data from the site’s actual users. I also attempted to collect a PageSpeed Insights result; the public endpoint returned HTTP 429, so I excluded it rather than filling the gap with an estimate.
The test is still useful because it demonstrates an auditable process. A client can open the raw timing file, see when the test ran, and compare a later capture after changes. For a paid engagement, I would add three to five runs per key page, a Lighthouse report, and field data from Search Console or the Chrome User Experience Report when available.
A repeatable seven-step service
1. Define the page set
Start with three pages: the homepage, the main service or product page, and the contact or checkout page. Ask the client which action matters on each page. A fast blog post does not compensate for a broken booking form, so the audit should follow the customer journey.
2. Record the test conditions
Write down the date, browser, viewport, connection setting, logged-in state, cookie state, and page URL. Test in a private window when possible. Run each page more than once and look for a consistent range instead of showcasing the best score.
3. Capture lab measurements
Use Lighthouse or PageSpeed Insights for a structured lab audit. Save the report rather than copying only the score. Scores can change when network conditions, browser versions, or page content change. The diagnostic details are more valuable than a colored circle.
4. Check real-user data
If the client has enough traffic, inspect the Core Web Vitals report in Google Search Console. Ask for read-only access and avoid exporting personal visitor data. If the site has no field data, say so plainly. Do not describe a lab test as a real-user result.
5. Inspect page weight and requests
HTTP Archive’s 2025 Web Almanac chapter on page weight reports median home-page weights of roughly 2.86 MB on desktop and 2.56 MB on mobile, and it shows a relationship between heavier pages and lower Core Web Vitals pass rates. That does not mean every page must be below a universal size. It does justify checking large images, third-party scripts, unused fonts, and video embeds before proposing a complex rebuild.
6. Turn findings into decisions
Group recommendations into three levels:
- Quick wins: resize oversized images, convert appropriate assets to WebP or AVIF, remove a duplicate font, or delay a nonessential embed.
- Theme or plugin work: change loading behavior, reduce render-blocking assets, or replace a heavy plugin after compatibility testing.
- Developer work: revise templates, caching, database queries, or application code.
WordPress’s image size and quality documentation is a useful primary reference when explaining generated image sizes and compression. Still, never bulk-delete or regenerate a client’s media library without a backup and a staging test.
7. Verify after each change
Save a before-and-after report using the same conditions. If several changes are deployed at once, you may not know which one caused a regression. For ecommerce and lead-generation sites, test forms, analytics, consent tools, checkout, and visual layout after optimization.
Where AI helps and where it does not
AI is useful for classifying repeated diagnostics, converting technical notes into client language, drafting a table of recommendations, and generating a checklist from a saved report. It can also help compare plugin documentation or write a test plan. Give it the actual evidence and ask it to cite the line or diagnostic behind each recommendation.
Do not let an AI assistant invent measurements, infer a business result from a performance score, or paste unreviewed code into production. It may suggest generic fixes that do not fit the client’s theme, host, cache, or consent setup. Remove secrets, user data, private URLs, and account identifiers before sharing logs with any model.
If you are building a broader service menu, pair this offer with a small-business AI workflow audit. The speed audit diagnoses the public website; the workflow audit looks at repetitive internal work. Both are easier to sell when the scope and evidence are concrete.
What to charge as a beginner
A realistic entry offer is $75 to $150 for one site and up to three public pages. Deliver a short report, the saved measurements, five prioritized recommendations, and a 20-minute review call. This is a planning deliverable, not implementation.
After you have a reliable checklist, a deeper audit might cost $250 to $600. That version can include more templates, repeat runs, Search Console review, a developer handoff, and one post-change verification. Implementation should be quoted separately because a plugin setting, custom theme, and ecommerce stack carry different risk.
Those ranges are positioning examples, not market guarantees. Your rate depends on region, technical depth, client size, liability, and how much access you need. Do not underprice work that requires production changes or emergency availability.
How to find the first clients
Choose one local niche such as accountants, home-service companies, or independent clinics. Review only public pages and send a short observation, not a frightening automated report. For example: “Your mobile hero image appears much larger than its display size. I can test the three pages that lead to your booking form and provide a prioritized, developer-ready report.”
Do not claim a site is losing a precise amount of revenue unless you have its analytics and a defensible model. Do not scrape contact lists or send deceptive mass outreach. A few relevant, permission-aware messages are safer than hundreds of generic warnings.
You can also publish a sample report using your own site, as I did here, while removing security details. Link it from a simple service page and explain the boundary between diagnosis and implementation. For more beginner monetization context, see the broader guide to making money with AI and this review of practical AI tools.
Costs, risks, and client protections
The basic tool cost can be $0: Chrome, Lighthouse, PageSpeed Insights, and Search Console are free. Your real costs are time, secure file storage, business insurance where appropriate, and possibly a staging environment or monitoring service. Paid tools may improve reporting, but they do not replace judgment.
Use a written scope. State that results vary, third-party scripts can change, field data takes time to update, and the audit does not guarantee rankings, accessibility compliance, sales, or uninterrupted service. Get written permission before accessing analytics or making changes. Use separate accounts, least-privilege access, and a password manager. If you implement a fix, keep a rollback path and confirm who is responsible for backups.
Disclosure: This article contains no sponsored recommendation. The dated test used AIHustlePath.com, a site connected to this publication. It was a single controlled browser observation and should not be treated as an independent endorsement or comprehensive performance certification.
A practical deliverable
Your final PDF or shared document can be five sections: scope and conditions, executive summary, evidence by page, prioritized recommendations, and verification plan. Attach the original reports. Mark each recommendation with expected effort, risk, owner, and the measurement that will be repeated.
That is enough to create a legitimate beginner service. The value is not an AI-written scorecard. It is a careful record that helps a business decide what to fix first, what to leave alone, and how to tell whether the work succeeded.
