Dad’s Life (https://dadslife.at/) is the largest community of fathers in the German-speaking world. Their website has blog posts, guides, and life tips and tricks for fathers all over the world.
Naturally, fast load times are crucial for the website’s user experience and its SEO after Google’s page experience update.
Since the beginning of 2021, the website has relied on NitroPack for its web performance needs. Roman from Dad’s Life tells us why they decided to give our service a shot:
Today, a few months after initially setting up NitroPack, the website passes its Core Web Vitals assessment with flying colors on mobile:
In this case study, we’ll look at how NitroPack makes these results possible. First, a bit of background about the site’s tech stack.
Unfortunately, a lot of WordPress sites tend to have poor Core Web Vitals scores, especially when using a lot of plugins. This is where an all-in-one speed optimization solution like NitroPack can help.
Most pages on the website did fairly well in the Cumulative Layout Shift (CLS) and First Input Delay (FID) categories, even though the lab data suggest issues with interactivity metrics.
Here are the lab metrics for the website’s homepage without NitroPack running:
While these are only lab results, a Largest Contentful Paint (LCP) time of 5s is still worrying. As it turns out, boosting the website’s LCP is where NitroPack makes a huge difference.
Here are the lab results with NitroPack:
So, lab data shows a massive improvement. However, these metrics don’t take into account real page loads, so let’s see what field data tells us.
Using the Core Web Vitals assessment, we can see that LCP is in the green zone (under 2.5s) for over 93% of all mobile page loads and 80% of desktop ones.
We can also use NitroPack’s Telemetry reports to compare this metric on non-optimized versus optimized pages:
As you can see, the LCP on non-optimized pages varies quite a lot. On the flip side, pages optimized by NitroPack have consistently great LCP scores in over 90% of cases. Again, this data comes from real users - the ultimate test for a website’s performance.
As we dive deeper into the website, we can see that three optimization categories play the biggest role:
Reducing Time to First Byte (TTFB) via caching;
Implementing a resource loading strategy;
TTFB measures how long the client waits to receive the first byte of data from the server. A slow TTFB leads to visitors staring at a blank screen, which is a surefire way to get them to bounce.
In terms of the Core Web Vitals, LCP (and FCP) depends highly on TTFB. In other words, if the TTFB for a page’s main document is too high, the LCP score also takes a hit.
We can use WebPageTest’s waterfall chart to see if that’s the case. Here’s the waterfall chart and TTFB for the homepage, without NitroPack:
907ms is way too long. Ideally, you want to be shooting for something under 200ms or, if that’s not possible - for the 200 to 500ms range.
Here, NitroPack’s advanced caching mechanism reduces TTFB and improves performance in general. By simply applying page caching, the TTFB is almost 7 times lower when testing from the same location:
We can also compare this metric for real page loads on non-optimized vs. optimized pages using our Telemetry reports.
Again, there’s a significant and consistent lift when using NitroPack. This is also evident by the high cache hit ratio:
This metric shows the percentage of requests that were served from the cache. A higher cache hit ratio means lower overhead for the origin server and faster load times for most visitors.
Over the last week, the cache hit ratio for this website varied between 85% and 99%, which is excellent.
The next step towards a better LCP (and faster site speed in general) is to optimize the order in which resources are loaded. Here’s that order without NitroPack:
There are two big issues here:
First, resources 2-20 are render-blocking. When the browser encounters them, it has to download, parse, and execute each one before doing anything else. As you can see, this takes quite a bit of time, especially with the last resource, which is Google’s third-party analytics script;
Second, the image which triggers the LCP metric is loaded after 33 other resources.
Our service rearranges the way resources are fed to the main thread to avoid blocking time. This speedÑ up rendering and improves interactivity metrics;
NitroPack inlines the CSS responsible for above the fold elements (Critical CSS) in the page’s head tag. This technique prevents render-blocking CSS;
NitroPack also delays the loading of non-critical resources until user interaction is detected;
Here’s the waterfall chart with NitroPack running:
As you can see, there’s one render-blocking CSS file left, which takes up only 53ms.
Also, the LCP element is now loaded much earlier:
The final piece of our puzzle is image optimization. Why? Because images are the largest element on most of the website's pages, and if they aren’t rendered quickly, the LCP score will plummet.
For example, here’s the LCP element on the homepage:
We already saw how this element was loaded earlier with our resource loading strategy. Now, we have to ensure that the image is loaded quickly on client devices.
NitroPack’s complete image optimization stack takes care of that. Here’s how:
First, our service converts images to WebP, compress them, and serves them through our Content Delivery Network (CDN);
Our service also defers (lazy loads) all offscreen images, including background ones;
When needed, NitroPack users can enable Adaptive Image Sizing, ensuring images fit their containers perfectly.
As a result, all image optimization audits in PageSpeed Insights are in the green and the website consistently gets great LCP scores.
As we said in our previous case study, improving web performance is ultimately about the user experience.
You shouldn’t obsess over any metric, even if it’s commissioned by Google. It’s all about ensuring the best possible experience on the web. And that was the exact effect on the website above:
Evgeni writes about site speed and makes sure everything we publish is awesome.