After a lot and fun work for over a year, varied from things that were low-effort to a few that were advanced, we’ve done it.

We’ve made Skroutz.gr faster.

Performance is a feature at Skroutz. But it is also a competitive advantage. Optimized experiences lead to higher user engagement, conversions, and ROI.

1. The science behind Web Vitals was kind of weak, referencing many studies that Gilles Dubuc showed us were based more on feelings than science.
2. You could only get those metrics from Chromium. Are they really Google Web Vitals if you only can get them from one of the browser engines? I think if we’re introducing something that’s supposed to be vital for all users, it should exist in all browsers.
3. Almost all performance tools implemented the metrics (for Chrome) immediately. Google said jump, and web performance tool vendors said: ‘How high?’. A little more caution would have been good. I also felt the pressure of adding those metrics to the tools I build. Google’s monopoly on web performance metrics is not good for the web, I think.

Let’s stop here and recap:

• Individual experiences are just data points along a distribution. What feels fast depends on the conditions under which it was experienced. Everyone’s conditions are different.
• Lab tests may not be configured to be representative of the most common experiences on the curve, or any experience on the curve for that matter.
• User-centric metrics require extra care to ensure that behaviors are emulated faithfully in the lab.

[…] An even better solution would be to build stronger data bridges between field and lab tools, so that the lab tool itself can make informed recommendations about the most realistic user profiles to simulate.

I have worked on many sites and projects over the years, and I have found the single best way to ensure that quality is a core area of focus, is to make that work visible and easily understood. We must do more than just make things faster; we must be able to explain what we did and what impact it had.

tl;dr: Use traffic frequency as cadence and create cohorts. Effects of improved web performance can show better in a well-defined cohort. Regular users can have trained behavior that resists change.

Embedding the resource directly removes the latency that’s incurred when the browser makes a separate request for the resource and so for critical resources it can make pages render faster.

But data URIs also come with quite a few trade offs too.

In this article, we will explore some of these native solutions that are available to the majority of your users. We will see some examples but we won’t go into all the subtleties, because other resources do so very well. Rather, the goal is to inform you of the existence of these techniques.

First-party JavaScript often impacts the interaction readiness of modern pages on the web, but it can often get delayed on the network behind non-critical JS from either first or third-party sources that keep the main thread busy.