Performance-first WordPress for a real business site: decisions that helped us reach 98 on mobile

Heorhii Lavrynenko — Sat, 24 Oct 2026 18:48:13 +0000

Editorial note: publish as a technical story. Keep the single homepage benchmark in scope, rather than implying site-wide 98 scores. If DEV requests a canonical for a close duplicate, set it to the case URL; this is a distinct English adaptation.

I recently worked on the website for a small digital-marketing project in Spain. It needed the things most business websites need: service landing pages, an editorial section, contact forms, analytics, a consent interface, and room to grow.

We used WordPress, Kadence, and the Gutenberg editor. One of my goals was to avoid turning performance into a separate rescue project after the design was finished.

The homepage eventually recorded a 98/100 mobile Performance score and 98/100 desktop score in PageSpeed Insights on October 22, 2026. GTmetrix rated it A in a separate test.

Here are the choices I think mattered most.

1. A familiar theme, but controlled components

We did not build a CMS from scratch. Kadence gave us the foundation, and Gutenberg made content editing practical.

For shared interface elements such as the header and footer, we used small custom modules rather than introducing an all-purpose visual builder for every detail.

We also reused page patterns for services, sectors, and locations without making every landing page identical. The same structure can support very different content, but each page should still answer its own question.

2. CSS before another JavaScript dependency

Menus, forms, consent, and some components require JavaScript. That is fine.

For animations and responsive layout, though, I preferred native CSS whenever it could do the job. I wanted to avoid adding a whole library for a small visual effect.

The important question was not "Can I remove every script?" It was "What work does this script do, and does every page need it?"

3. Images are a layout and loading problem, not just a format problem

We prepared most content images in WebP and used different hero assets for mobile and desktop where needed.

Above-the-fold imagery received a different loading priority from images lower down the page.

The goal was not just a smaller file. It was to give the browser the right asset early enough for the first screen to make sense.

4. Self-hosted fonts

We used locally hosted Inter WOFF2 files, with font-display: swap and a priority for the font needed early in the page.

Fonts are easy to ignore in performance discussions, but their loading behavior affects how the first content appears.

5. Third-party tags need deliberate placement

Business sites need measurement. Ours also needed Google Tag Manager and a consent flow.

We separated early consent initialization from later analytics loading and controlled how third-party code entered the page.

This comes with a trade-off: delaying tracking can affect the capture of short visits and early interactions. That is why I treat measurement integrity as part of the performance work, not something to sacrifice for the score.

Results and context

The homepage test on October 22 showed 98/100 in mobile Performance, 98/100 in desktop Performance, and 100/100 in the Lighthouse SEO category. GTmetrix gave the homepage an A grade in its October 20 report.

Those are snapshots of a specific page, not a universal score for every URL or real-user metric.

Separately, Google Search Console recorded 106 organic clicks and 14,785 impressions between September 17 and October 20. We also worked on the site's content and SEO architecture, so I would not attribute that search growth to speed alone.

What I'd repeat

Start with the actual page types and the user journey. Define the components you need, think about loading priorities early, and measure the resulting pages.

It's much easier to stay disciplined with a WordPress site when performance is part of the design process rather than a late plugin-shopping exercise.

The full case, including screenshots and the Spanish write-up, is here:
https://mapalocal.es/casos-de-exito/mapalocal-wordpress-pagespeed-98/

I'm curious how other WordPress developers balance analytics and consent requirements with fast initial rendering.

DEV Community: Heorhii Lavrynenko