Web Performance Calendar

The speed geek's favorite time of year
2020 Edition
ABOUT THE AUTHOR
Photo of Peter Hedenskog

Peter Hedenskog (@soulislove) loves Open Source and really cares about the open web. Peter is one of the creators of the Open Source sitespeed.io web performance tools.

I hope you didn’t miss the session about The Future Of Core Web Vitals at Chrome Dev Summit 2020. I think it’s great that the Chrome team is open about the metrics and is looking for feedback!

When Google Web Vitals first was introduced there were three things that disturbed me:

  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.

At the moment the core Chrome Web Vitals consist of three metrics: Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS). I like them, they seem to be important and I can see how they affect the users but I would love a study of how they really affect the user. Do users really care about Largest Contentful Paint?

Upcoming changes

At the Chrome Dev session, the metrics team shared upcoming changes: Change the threshold for First Input Delay, better measuring layout shifts for long-lived sites and maybe making First Contentful Paint a core metric.

I think First Contentful Paint will be interesting and kind of hard to get right since I think it depends a lot on the users connectivity. If the user has a slow internet connection and accesses your web site, will your web page then have a lower score? Will it hurt websites that focus on people that live in areas where the connection is slow?

What I really liked about the session about changes in the metrics was that the metric team is thinking about adding more user experience metrics like security, privacy and accessibility.

Google Web Vitals including security, privacy and accessibility?

I really like performance but I think the web experience is so much more, so including more categories into Google Web Vitals seems to be the way to make the vital metrics something for all users and all browsers. I actually got excited, so today I sent a feedback email to the web vitals team:

Hi! My name is Peter and I wanted to give some feedback on future Google Web Vitals. I’ve been working on a tool called the Coach that gives users advice about web performance, web best practices and privacy. You people are the best on performance so I wanted to give feedback about privacy, since I think it would be great if it is included in Google’s Web Vitals and it is important that you get it right.

In the Coach I’ve been focusing on two different areas of measuring privacy:

  • Server setup: Making sure that the page uses HTTPS, does not mix HTTP/HTTPS content, sets a content security policy, referrer policy header and strict transport header.
  • Third party content: It’s important that web pages do not share user information with third party companies. As you know this happens without the user conceding on the web. So you need to check third party requests, cookies and if libraries like fingerprint.js are used to track the user. You need to make sure that the user is not tracked.

It would also be cool if your privacy advice would include CDNs, so that using a CDN will hurt the privacy score (since it will give the CDN company information about your user). This will conflict with getting a good FCP-score for web sites that have an audience around the world. But I’m sure you could find a good balance 🙂

I also think it would be cool to make it easy for other browser vendors to implement Google’s Web Vitals. One carrot for doing that could actually be the privacy advice! Let me explain:

Testing a page privacy will give the user a number between 0 and 1. If the page uses Google products like analytics, maps, fonts (yeah every request to a Google domain), the metric will always be the lowest one since the user will be tracked. The privacy score will be zero. I understand that this is against your company’s goals/business strategy but I’ve always been thinking that Google engineers have been good people and now it is time for you all to prove that. Remember it is Christmas time and we should all be nice 🙂

All the best
Peter

I think you should also take the opportunity to influence coming Google Web Vitals and write what you think should be included to web-vitals-feedback@googlegroups.com if you haven’t already!

One Response to “The future of Google’s Core Web Vitals from a non-Googler perspective”

  1. Andy Davies

    For better or for worse Web Vitals is what we’ve got and yes they’ve got shortcomings (targets are way too generous IMV)…

    The influence Google has over performance metrics, and the fact that Chrome is the only browser that supports most of the Web Vitals is an issue with other organisations and browsers involvement in the process.

    For example, why did WikiMedia have to fund someone to add support for the Paint Timing metrics to WebKit, instead of Apple doing it themselves?

    If we want to reduce Google’s influence other organisations have to step up.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
And here's a tool to convert HTML entities