WordPress Speed Audit: From Mobile Score 60 to 90+

The Starting Point: A Score in the Low 60s

What the Baseline Audit Revealed

The project began with a WordPress website that was approximately 99% ready for its public launch. The client had one remaining concern: performance. A PageSpeed Insights test run before the optimization engagement showed a mobile score in the low 60s. The target was 90 or above. GTmetrix showed similar results — the performance grade was below the level the client needed for both user experience and search visibility.

The baseline reports pointed to three primary issues: render-blocking JavaScript from the hero carousel, images not in next-gen format, and unused JavaScript from plugins that were loading scripts on pages where they were not needed. The server was already running LiteSpeed, and LiteSpeed Cache was installed but under-configured.

Why Mobile Score Is the One That Matters

Google uses mobile-first indexing, which means the mobile version of a page is the version used for ranking. A desktop score of 90 with a mobile score of 60 is a problem — the desktop number is largely irrelevant for SEO purposes. When a client asks about PageSpeed scores, always anchor the conversation to the mobile score. The desktop score is useful context but should not be the primary metric for an optimization engagement.

The Optimization Process

Phase 1: LiteSpeed Cache Configuration

The first step was reviewing and correcting the LiteSpeed Cache configuration. Public Cache was enabled, browser caching was confirmed active, and CSS and JS minification were enabled and tested. Critical CSS generation was forced via the cron button to clear a backlog of 98 queued requests. Object cache was left disabled — the hosting environment did not support Redis.

After these configuration changes, a PageSpeed test showed an improvement of approximately 8 to 10 points. Caching alone rarely gets a site to 90, but it is the foundation everything else builds on. An uncached site will fail to hold score improvements made at the application layer.

Phase 2: Image Optimization

With caching in place, the next phase was image optimization. The Send Optimization Request button was used to queue all 7,900+ images for processing through LiteSpeed’s optimization service. The service ran over several hours, ultimately reducing total image storage by 476 MB and converting all images to WebP.

After optimization, the archive page was checked using browser developer tools and found to still be serving JPG thumbnails for specific cropped image sizes. These were resolved by connecting via FTP and deleting the dimension-suffixed JPG files that had not been converted. Verification confirmed that the archive page thumbnails were then served as WebP.

Phase 3: JavaScript and Carousel

The hero carousel — implemented with Slick.js — was identified as the primary remaining LCP bottleneck. After caching and image optimization, the mobile score had improved but remained below 80. The carousel was contributing render-blocking delay that compressed images could not address.

JS Defer was enabled in LiteSpeed Cache, and the carousel initialization was restructured so that only the first slide loaded on initial render. This change brought the LCP time below the 2.5-second threshold that Google considers good, and the mobile score crossed 90 for the first time.

Phase 4: Lazy Load and Appear Effect

After the initial score target was achieved and the site went through a review period, a secondary issue emerged: on mobile devices, page content required a scroll gesture to appear. The issue was traced to a combination of lazy loading configured with too-low a threshold and a scroll-triggered appear animation applied to content blocks on the homepage.

Disabling the appear animation for above-the-fold content and adjusting the lazy load threshold resolved the issue. The page loaded completely on mobile without requiring a scroll to trigger content visibility.

The Final Results

PageSpeed Insights and GTmetrix After Optimization

After completing all four phases of optimization, the mobile PageSpeed score exceeded 90 — meeting the client’s stated target. GTmetrix reported a 100% performance grade and a 100% structure grade. The total image storage reduction of 476 MB translated to measurably faster page loads, particularly on mobile connections where bandwidth is limited.

The client’s end-user experience improved correspondingly. Page content appeared immediately on load without requiring scrolling. Featured images displayed correctly across all post types and archive pages. The site launched publicly with confidence in its performance baseline.

What Moved the Score and What Did Not

The changes that had the most measurable impact on the PageSpeed score, in order: fixing the carousel loading behavior, enabling LiteSpeed Cache correctly, converting images to WebP including thumbnails, and adjusting lazy load configuration. Plugin deactivation and other miscellaneous cleanup contributed small incremental improvements but were not significant on their own.

Key Takeaways for Future Projects

Audit before optimizing — establish a baseline score and identify the specific issues contributing to it before making any changes. Work in phases and test after each phase. Do not apply every optimization at once, because it becomes impossible to attribute score changes to specific interventions. Prioritize mobile score over desktop score because that is what determines search performance. And address JavaScript loading behavior — particularly carousel scripts — early, because no amount of image optimization will compensate for a render-blocking script on the critical rendering path.

This concludes the WordPress Speed Optimization series. Each article in this series documents a specific aspect of a real optimization project, from initial LiteSpeed Cache configuration through to post-launch lazy load fixes. The complete guide is available at the link below.