WordPress Speed Optimization Case Study: From 53 to 91 Mobile PageSpeed

Improving the performance of a live WordPress website is rarely about installing one cache plugin and pressing an “Optimize” button. Real production websites contain page builders, third-party add-ons, analytics scripts, large media libraries, external fonts, legacy assets, dynamic sections, and settings that may conflict with each other.

In this WordPress speed optimization case study, the Baza Developers team optimized a live construction company website built with WordPress, Elementor, Astra, and several Elementor add-ons. The work was completed during one focused working day with the help of Baza Helper.

The mobile PageSpeed performance score increased from 53 to 91. Accessibility reached 100, Total Blocking Time dropped to 100 ms, and the server response measured by Lighthouse improved to approximately 370 ms.

Project overview

The initial performance problems

The website looked correct to visitors, but its mobile performance was held back by several independent issues. Solving only one of them was not enough because the loading process contained multiple bottlenecks.

• The hero section used a background slideshow and requested additional slides during the critical loading period.
• The Largest Contentful Paint image was large and was not always discovered with the correct priority.
• CSS and JavaScript files from Elementor and several add-ons loaded globally.
• Google Fonts requested multiple families, weights and language subsets.
• Font Awesome icon files were loaded even where lightweight SVG alternatives could be used.
• Google Tag Manager and Google Ads added hundreds of kilobytes of third-party JavaScript.
• Static assets did not initially have an effective long browser cache lifetime.
• Several plugins added frontend assets that were no longer required.
• Some images were missing useful alternative text in the rendered HTML.
• Page caching and mobile cache behavior required separate verification.

Results before and after optimization

PageSpeed Insights is a laboratory test and individual results can fluctuate because of simulated network and CPU conditions. For this reason, we compared repeated tests and verified important changes directly in the browser and on the server.

How Baza Helper supported the optimization

Baza Helper provided one place to inspect and improve several important areas of WordPress performance. Instead of adding separate optimization plugins for images, fonts, caching, analytics, Elementor, and asset management, the team could work through a coordinated toolset.

1. Page caching and server response

Public page caching was enabled while keeping sensitive and personalized routes outside the cache. Account pages, administrative requests, URL variations and other excluded paths continued to bypass public caching.

Desktop and mobile requests were tested independently. Repeated mobile requests returned a Baza cache hit with server-side Time to First Byte between approximately 0.25 and 0.28 seconds.

This confirmed that the WordPress page cache worked correctly for a mobile user agent. The higher value shown by Lighthouse also included its simulated mobile network latency and should not be interpreted as PHP execution time alone.

2. Hero slideshow and LCP optimization

The original first screen used an Elementor background slideshow. Additional slides competed for bandwidth during the most important part of the loading process and could change which visual element became the final LCP candidate.

The slideshow was replaced with a stable hero background. The first visible background was converted to AVIF, loaded eagerly, and made discoverable from the initial page response. Baza Helper also learned the correct responsive background candidate and generated an image preload for subsequent requests.

• The LCP image was no longer lazy-loaded.
• The browser could discover the resource from the initial document.
• Unnecessary slide requests were removed from the critical loading period.
• The final layout remained visually stable.
• A separate mobile-sized image could be used without changing the desktop design.

3. WebP and AVIF image delivery

Baza Helper generated modern WebP and AVIF versions of WordPress media, responsive image sizes, theme assets, plugin images and images discovered inside rendered pages.

The frontend image manager selected AVIF where supported, used WebP as the next option, and preserved the original file as a fallback. Files larger than the original were not retained. Image conversion ran in bounded background batches so the media library could be processed without one long blocking request.

After optimization, Lighthouse no longer reported an image-delivery opportunity for the tested page.

4. Google Fonts cleanup

The website initially requested Roboto, Roboto Slab and Open Sans with many weights and italic variants. That created unnecessary font CSS, external connections and multiple WOFF2 downloads.

The typography was consolidated around Roboto with the weights actually needed by the design. Explicit Open Sans declarations inside individual Elementor add-on widgets were replaced. Unused font families stopped downloading, and the final report contained no external Google Font resources.

5. Font Awesome and icon optimization

Font Awesome brand and solid icon fonts added CSS and large WOFF2 resources to the critical request chain. Where possible, these font-based icons were replaced with lightweight SVG or CSS mask icons.

Unused Font Awesome handles were disabled only after checking the rendered page. This removed unnecessary font downloads without hiding interface controls or social icons.

6. Conditional CSS and JavaScript management

The site used Elementor together with Happy Addons, Royal Addons and other extensions. Each plugin could register frontend assets even when only a small part of its functionality was used.

Baza Helper helped identify WordPress asset handles and their approximate weight. Unused assets were disabled carefully, page by page, while required dependencies were preserved.

• CSS combining was disabled after testing showed that separate delivery performed better for this website.
• jQuery Migrate was removed after verifying menus, counters, carousels and forms.
• Core jQuery remained enabled because Elementor and active widgets still depended on it.
• Isotope-related assets were removed after the original filterable gallery was replaced.
• Popup Builder was removed when it was no longer required.
• Critical CSS was regenerated after icon and typography changes.

The final report still identified a small amount of blocking time from core jQuery. It was intentionally preserved because removing a required dependency for a minor score increase would create a faster but broken website.

7. Analytics and third-party scripts

Google Tag Manager and a Google Ads destination loaded more than 300 KB of third-party JavaScript during earlier tests. The team did not have access to audit the existing GTM container, so it could not safely verify tag ownership, duplicate page views, conversion configuration or consent behavior.

GTM was temporarily disabled until the container can be reviewed and configured correctly. This removed the third-party execution cost from the tested page. Baza Helper can manage GA4, GTM, Meta Pixel, Microsoft Clarity and Google Ads through consent-aware provider settings, but analytics should never be enabled without validating ownership and measurement requirements.

This change also demonstrates an important performance principle: third-party scripts should be treated as product decisions, not automatically injected into every page.

8. Browser caching for static files

Long-lived browser caching was configured for versioned CSS, JavaScript, fonts and images. This allows returning visitors to reuse static resources instead of downloading them again on every page view.

Page caching and browser caching were handled separately. HTML remained safely invalidated when WordPress content or theme settings changed, while static files could use a longer lifetime.

9. Accessibility improvements

Performance work should not reduce accessibility. The rendered image markup was inspected after AVIF and WebP rewriting, and missing alternative text was traced back to the source widgets and attachment data.

Media attachment IDs and alternative text were preserved through image conversion. The final Lighthouse accessibility score reached 100.

What Baza Helper handled in this project

Why the final score was not forced to 100

The objective was not to manipulate a laboratory score. The objective was to make a real production website faster while preserving its design, content and interactions.

The final Lighthouse report still identified approximately 59 KB of unused CSS and a small blocking cost from jQuery. Removing those resources without complete route-level and interaction testing could break Elementor widgets or content below the first screen.

A stable score of 91 with working navigation, forms, counters, responsive layouts and accessible content is more valuable than an artificial score of 100 produced by hiding content or delaying essential functionality.

Key lessons from this WordPress optimization case study

1. Start with measurements, not assumptions.
2. Test mobile and desktop cache behavior independently.
3. Optimize the real LCP resource before adding more preloads.
4. Do not lazy-load the first visible hero image.
5. Reduce font families before trying to optimize every individual font file.
6. Remove plugin assets only after identifying their WordPress handles and dependencies.
7. Third-party analytics can cost more than the website’s own JavaScript.
8. Regenerate critical CSS after changing fonts, icons or page-builder assets.
9. Repeat tests because Lighthouse scores naturally fluctuate.
10. Never trade working functionality or accessibility for a synthetic score.

Who can benefit from Baza Helper?

Baza Helper is designed for WordPress teams that want one coordinated toolkit for performance, content, technical SEO, diagnostics and development tasks.

• Business websites built with Elementor
• WordPress agencies managing multiple client projects
• Websites with large media libraries
• Projects using several Elementor add-ons
• Sites affected by slow mobile PageSpeed results
• Teams that need controlled asset unloading
• Websites requiring WebP and AVIF generation
• Projects that need safer page and browser caching

Frequently asked questions

Can one WordPress plugin guarantee a PageSpeed score of 90 or higher?

No. Performance depends on hosting, the active theme, plugins, page-builder structure, media, third-party scripts and the tested network conditions. Baza Helper provides optimization and diagnostic tools, but each production website still requires measurement and verification.

Does Baza Helper replace a cache plugin?

Baza Helper includes public page caching and browser cache controls. Whether it should replace an existing cache layer depends on the hosting stack, reverse proxy, CDN and other active optimization tools. Two page caches should not compete for ownership of the same response.

Can Baza Helper optimize Elementor websites?

Yes. It can help identify Elementor assets, optimize images and backgrounds, manage fonts, improve caching and provide controls for scripts and styles. Assets should still be disabled carefully because Elementor widgets may share dependencies.

Why did the team keep jQuery?

The tested site still used Elementor components that depended on core jQuery. Its remaining cost was smaller than the risk of breaking menus, counters, forms or carousels. jQuery Migrate was removed only after the relevant interactions were tested.

How long did the optimization take?

The audit, configuration, repeated testing and verification were completed during one focused working day. Larger websites may require additional time for media conversion, template testing, analytics access and validation across multiple page types.

Final result

The optimized website reached a mobile PageSpeed performance score of 91 while maintaining a stable layout, working Elementor interactions and full Lighthouse accessibility.

The biggest improvement did not come from one isolated switch. It came from treating WordPress performance as a complete delivery system: caching, LCP discovery, responsive images, fonts, CSS, JavaScript, plugins, analytics and accessibility.

If your WordPress website has a slow mobile experience, Baza Developers can audit the actual loading path, identify the most expensive resources and apply changes that improve performance without sacrificing functionality.