WordPress
Background
Managed Server SRL is an Italian company providing managed hosting and high-performance Linux systems engineering. The company website runs on WordPress with the Astra theme and the Elementor page builder, on a carefully tuned server stack: nginx with TLS, HTTP/2 and HTTP/3, Varnish as page cache, PHP-FPM and MariaDB, with Autoptimize for CSS and JavaScript aggregation. The home page is made up of 34 sections and about 3,300 DOM elements.
This case is unusual: the site was already fast for real users. The goal was not to pass the Core Web Vitals but to get a lab score consistent with the real experience, without resorting to optimization services that push JavaScript beyond the measurement window and make the page behave differently during tests. The work is documented in detail in the account of the optimization published by Managed Server.
What the data said
The Chrome UX Report field data was already excellent: LCP 0.7 seconds, INP 73 milliseconds and CLS 0. PageSpeed Insights on mobile, however, swung between 76 and 86 points, with First Contentful Paint between 2.0 and 2.4 seconds, Largest Contentful Paint between 3.8 and 5.3 seconds, Speed Index between 3.3 and 5.0 seconds, Total Blocking Time between 0 and 100 milliseconds and CLS at 0. On desktop the score was already between 97 and 100.
The gap between field and lab is explained by the test conditions: an emulated mobile device with a throttled CPU and a slow network exposes costs that real users, with better devices and connections, barely notice. They are real costs for the tail of slower users, though, which is why they were worth eliminating.
The diagnosis
Analysis with local Lighthouse runs, the raw PageSpeed Insights JSON and Chrome DevTools traces isolated a few causes, each with a precise weight:
- heavy HTML document: 128 KB compressed, of which 71 KB was inline SVG on the mobile home page alone, almost a quarter of the document; a single icon weighed about 100 KB uncompressed;
- LCP render delay between 1,050 and 2,112 milliseconds: the main element was ready, but the browser painted it late because of render-blocking CSS and layout work;
- JavaScript forcing layout of sections that were not visible, such as the script that stretches sections to full width;
- suboptimal fonts and preloads: 14 unused latin-ext faces of Open Sans and a preload of a below-the-fold font that made LCP 170 milliseconds worse.
Server-side work
- nginx microcache in front of Varnish, with background update and the previous copy as fallback: fewer requests to Varnish and PHP-FPM and more resilience;
- compression moved to the backend, removing 30-40 milliseconds of CPU on the frontend: Brotli 9 and Zstandard 15 for HTML, Brotli 11 and Zstandard 19 for the Autoptimize files, which have a long cache lifetime;
- fix for an intermittent read error between nginx and the backend, present in about 1.5% of requests and caused by expired keepalive connections, solved with
keepalive_timeout 0on the backend; - Varnish memory raised from 512 MB to 2 GB;
- cache warming for 781 URLs, two devices and three encodings, 4,386 requests in about three and a quarter hours, run gently: 24 HITs out of 24 in spot checks, with responses between 22 and 48 milliseconds.
Application-side work
- SVG out of the document, the main lever: inline icons were moved to separate files, loaded when needed, and compressed HTML dropped from 128 to 62 KB;
- critical CSS per page and device, generated with Penthouse on 47 pages in mobile and desktop versions, with JavaScript enabled to apply Astra’s classes: from about 130 KB down to 55-60 KB;
content-visibility: autoon below-the-fold sections, withcontain-intrinsic-sizemeasured for each section and device so as not to cause shifts; the mobile footer, 4,400 pixels tall, drops out of the initial render;- layout without JavaScript: the Elementor script that stretched sections was replaced by CSS; of the 18 sections involved, 15 were already as wide as the window and 3 were solved with
width: 100vwandmargin-left: calc(50% - 50vw); - fonts: unused faces removed, a 10 KB Font Awesome icon replaced by a 457-byte SVG, preloads kept only where measurably useful;
- measured JavaScript deferral: jQuery deferred with a small compatibility shim, wp-i18n and wp-hooks removed where unused, cookie banner, tooltips and chat loaded later, analytics in compliance with consent, without postponing the initialization of visible components.
Results
The first round of work, about 20 hours, brought the mobile score to 98 with an LCP of 2.3 seconds and the LCP render delay from over a second down to 130 milliseconds. With the later refinements, the current PageSpeed Insights measurement on mobile is 100 points:
| Metric (lab, mobile) | Before | After |
|---|---|---|
| PageSpeed Insights score | 76-86 | 100 |
| First Contentful Paint | 2.0-2.4 s | 1.2 s |
| Largest Contentful Paint | 3.8-5.3 s | 1.7 s |
| Total Blocking Time | 0-100 ms | 0 ms |
| Cumulative Layout Shift | 0 | 0 |
| Speed Index | 3.3-5.0 s | 1.8 s |
| Compressed HTML | 128 KB | 62 KB |
The field data stayed green, as before. That is the point of this case: the score now describes a site that is genuinely fast, achieved by reducing the browser’s work rather than moving it outside the measurement window.
How we maintain the result
Critical CSS has to be regenerated when a page’s layout changes, and every new below-the-fold section needs its own contain-intrinsic-size measurement. Every change is verified with multiple Lighthouse runs, because a single test is not enough to tell an improvement from noise, and Chrome UX Report data remains the final reference. A few points were deliberately postponed, such as critical CSS limited to the first fold only, which would gain 35-50 milliseconds at the price of a risk of shifts, and aligning the font metrics on the pricing page.