EAGLE SOLUTIONS
Google PageSpeed Insights (pagespeed.web.dev) is free and anyone can run it on any website – that is why I like it: a client does not have to take my word for it, they can rely on their own measurement. The 11 September 2026 measurement of eaglesolutions.ro shows the same on mobile and desktop: 100 performance, 100 accessibility, 100 best practices, 100 SEO. This article is about what it took to get there, and what I deliberately did not do.
What does PageSpeed actually measure?
It gives four scores. Performance shows how quickly the page appears and becomes usable on an average phone over a slower network. Accessibility looks at contrast, image alt text and keyboard operability. Best practices cover security and modern standards (HTTPS, an error-free console, up-to-date image formats). SEO checks the search basics: titles, descriptions, crawlability, mobile-friendly display. Performance is the hardest one: most WordPress sites sit between 40 and 70 points on mobile.
1. A custom block theme, no page builder
The biggest decision: the site was not built with Elementor or any other visual page builder, but with a custom theme built on WordPress's own block system. Page builders are convenient, but they load hundreds of kilobytes of their own CSS and JavaScript on every page – even when that page does not use a single bit of it. A block theme only loads what the page actually uses. On client projects this is the first question too: is a page builder needed at all, or would it only get in out of habit?
2. Few plugins, each one justified
Five plugins run on the site: SEO, contact form, multilingual support, cookie management and the security firewall. Caching is the host's own server-level solution. Every other feature – structured data, conversion tracking, the monthly report – is handled by small custom code that does exactly what is needed and nothing else.
3. Caching and the server
The host provides a LiteSpeed server, with the LiteSpeed Cache plugin, an object cache (Memcached) and a content delivery network (CDN). This means that when a visitor makes a request, in most cases a ready-made HTML page is served from the server closest to them, without a database query. The first byte arrives well under half a second – that is the foundation for everything else.
4. Images: WebP, sized to fit, lazy loaded
Every image is in WebP format, in variants matched to the display size, and only loads when the visitor scrolls near it. The main above-the-fold image is the exception: the browser requests it immediately, with high priority, so that the largest element (LCP) appears fast. The portfolio screenshots and the blog covers are produced the same way.
5. Tracking scripts only after consent
Google Analytics and every other external script only loads once the visitor has accepted in the cookie banner – this is a GDPR obligation, but as a side effect it also lightens the initial load. There is no chat widget, no auto-loading video, and the WhatsApp button is a plain link.
6. What I left out, deliberately
No font library from an external server, no slider on the homepage, no animation framework. The subtle reveal animations are a few lines of custom CSS and JavaScript. For every "pretty" element I asked: does it bring in clients, or does it only slow things down?
The last points: from 99 to 100
The previous day's measurement still showed 99 performance and 95 accessibility. I first suspected a contrast issue, but the Lighthouse report said otherwise: the heading order skipped a level (an h4 right after an h2), which is an accessibility error because screen readers build the page outline from headings. Fixing two heading levels took it to 100. On performance, a single mobile run even returned 88 with an 8-second Speed Index; the next run was 100. Lab values fluctuate, which is why I look at the average of several runs, not a single screenshot. The same day I also cut the font file to a quarter (84 instead of 327 kilobytes, only the Hungarian-Romanian-English character set) to keep some headroom on slow mobile networks.
What does this mean for a client project?
I apply the same principles to business websites and online stores: a page builder only when justified, few plugins, server-level caching, WebP images, consent-gated tracking. Even on an existing, slow site most of the points can be won back – I described the seven most important steps in a separate article. If you are curious where your own site stands, measure it on pagespeed.web.dev and send me the result via the contact page – I will tell you for free what is slowing it down.
