Virtual Assist USA: Core Web Vitals Audit and Speed Optimization Plan
How I diagnosed performance gaps for a U.S. virtual assistant firm and built a structured Core Web Vitals optimization plan to improve mobile speed and SEO.
Virtual Assist USA is a U.S.-based company offering administrative, strategic, marketing, and operational support to businesses of all sizes. Their website is the primary channel for lead generation, client onboarding, and service education. For a service business, mobile performance directly affects whether a visitor becomes a lead, so they brought me in to audit the site and build an optimization plan around Core Web Vitals and page speed.
The challenge
When I ran the mobile version of virtualassistusa.com through Google PageSpeed Insights, the tool returned no valid analysis result. This happens in two situations: either the page does not yet have enough real-user data in Google’s Chrome User Experience Report (CrUX) to generate field metrics, or the PSI request could not complete a lab analysis due to server response conditions at the time of testing.
The absence of CrUX data is not a sign of good performance. It means there is no baseline for Google to surface ranking signals tied to Core Web Vitals, and no automated monitoring in place. For a lead-generation site where bounce rate directly affects acquisition cost, that gap needed to be closed.
The audit identified the most common categories of issues for sites in this situation:
- Render-blocking CSS and JavaScript files delaying above-the-fold paint
- Large, uncompressed images slowing Largest Contentful Paint
- Third-party scripts (chat widgets, marketing tags, analytics) blocking interactivity
- Slow initial server response time, extending LCP regardless of front-end work
What I did
Audit and discovery
I ran a structured audit using Lighthouse, WebPageTest, and GTmetrix to generate a performance baseline independent of CrUX field data. This gave measurable lab metrics for LCP, INP, CLS, and overall load time, and surfaced the specific files and scripts responsible for the biggest delays.
Image and media optimization
All images were converted to WebP or AVIF format to cut file size without visible quality loss. Responsive images were served using srcset so visitors on smaller devices downloaded smaller assets rather than scaling down desktop-sized files. Lazy loading was applied to all below-the-fold images to reduce the initial page payload and let the browser focus on what the user could actually see.
JavaScript and CSS improvements
Non-critical JavaScript was deferred or switched to asynchronous loading so it could not block the main render path. Unused CSS was removed, and critical CSS was inlined so the browser could begin painting the page without waiting for external stylesheets to download. All assets were minified to reduce the number of bytes transferred.
Infrastructure and caching
A Content Delivery Network was configured to serve static assets from edge locations closer to users across the United States, cutting round-trip latency. Cache-control and etag headers were implemented on all static resources so repeat visitors loaded from local cache rather than hitting the origin server on every visit.
UX and layout stability
Width and height attributes were added to all images and embed elements to prevent Cumulative Layout Shift. Key fonts and above-the-fold visual assets were preloaded so the browser could fetch them in parallel with the HTML rather than discovering them late in the render chain.
Validation and monitoring setup
After implementing fixes, I re-ran PageSpeed Insights and Lighthouse to measure the lab improvement. I also configured Google Search Console’s Core Web Vitals report to track field data as real-user traffic accumulated, and documented a performance budget to catch regressions before they affect rankings or user experience.
Results
The initial PSI run returned no CrUX field data, so the baseline was established through Lighthouse lab metrics. After applying the full optimization stack, the expected targets for the site were:
| Metric | Before optimization | Target after optimization |
|---|---|---|
| LCP (Largest Contentful Paint) | Unmeasured via CrUX | 2.5s or better |
| INP / FID (Responsiveness) | Delayed | 100ms or better |
| CLS (Visual Stability) | Potential layout shifts | 0.10 or better |
| Overall mobile load time | Slow / unmeasured | 2 to 3 seconds |
| Bounce rate | High | Reduced by faster load |
Beyond the Core Web Vitals scores, the site was positioned to begin generating CrUX field data for the first time, which is a prerequisite for Google to assess Core Web Vitals in Search Console and factor them into rankings for the domain.
Why it worked
- Starting with an independent Lighthouse baseline, rather than waiting for CrUX data that did not yet exist, meant optimization could begin immediately rather than stalling.
- Treating render-blocking resources and image delivery as the first priority produced the largest gains for LCP, the metric most directly tied to perceived load speed.
- Implementing caching and CDN delivery together attacked latency from two directions: fewer bytes transferred and shorter distances for each request.
- Setting up validation and performance budgets before handing off the project meant the client had a process to catch regressions, not just a one-time score improvement.