Increasing the Lowest Common Denominator for Web Performance | by Emil Hein | Jun, 2022

Chrome has a new Performance Insights feature. Let’s look at the new design, that should help us understand performance better. Together with Lighthouse, this might help everyone.

0*t9 NaflcBZi0nCfs
Photo by Alex Padurariu on Unsplash

Performance testing and debugging has always been complex and kind of tricky for people (myself including). I believe the root cause is, that there is a large amount of data that need to be presented in a meaningful way.
Like many other systems, you can have all the data in the world, but if you can’t present it correctly, no human can understand it and take the necessary actions.

Most web developers will have encountered a situation like this

Client: The website is slow
You: It’s pretty fast on my computer

Ok, how do we proceed from here? There might be 2 million things affecting the experience for both of you!

In regard to Chrome’s new tab, you can read a thorough guide from Google here. What I really want to talk about in this context is how I think the new UI, might be a step in the right direction of having an information conversation about performance.

From the perspective of a developer, you have to face this discussion with a wide variety of people, that all have a different level of knowledge, about the subject.

Many site owners, big and small, are thankfully becoming more and more technical. If not, they really should. I believe this to be a good thing, as the general site owner gets more technical knowledge. But with more technical knowledge comes more questions. Let me illustrate!

  1. From your grandma’s perspective, a website is either loading fast or slow.
  2. From your boss’s (the site owner) perspective, your site should limit the number of HTTP requests.
  3. From your perspective (the developer) you know that you need to limit the HTTP request, limit the number of redirects, limit the render-blocking request, minimize bundle size, minimize image sizes, improve caching in the different layers, improve API performance, minimize CLS, getting the first paint ready as soon as possible, avoid render-blocking computation, etc…

I think you get the point. The deeper the knowledge, the more aspects of the real problem is known to you. Now, I would imagine you would have a pretty hard time explaining your grandma anything from point 3. And that’s fine, as the client only needs to know if the site is slow or fast.

Explaining/discussing a site’s performance with your boss should be an informed discussion, with the basis on some real data (as some performance is subjective). Contrary to your grandma, it might be a bit easier to explain some of the stuff in point 3, to your boss.

1* TfqroFUo34rNUIroE w A
Leveling up the lowest common denominator

Of course, your boss is not expected to know the same things about site performance as a developer, after all, that’s why they hired you. And that is all fine and good, but the higher the level you can discuss, the more productive the conversation you can have. So how can we raise the knowledge gap, without teaching our boss how to code?

This is where the “performance Insights” is going to help us, raising the lowest common denominator between you and your boss.
Some might already know the tool Lighthouse, which collects a lot of data from your site, from different categories, and display them in a very pleasant way, that helps non-technical people understand some of the aspects surrounding a website in general.

Performance insights are trying to do some of the same things as Lighthouse, but specifically only looking at performance and Web vitals, but in greater depth.

The concept of Web vitals, that in part determines your Google ranking and overall perceived performance, can be difficult to pinpoint and visualize. The new tab in Chrome helps us get a snapshot of a page load and give us some very specific information about what is causing the different data points.

This information is not anything new, we have been able to get this information for years and years. The thing that is different is the accessibility. Previously this data would only be available to developers who knew what they were looking for. Before Lighthouse, data like this, would not even be remotely accessible for non-developers.

Look at this

1*IxBy0lZsX DZLeQT Cj1UA
The new tab

This looks like it’s almost made for web users.

I still believe it’s mostly developers that even open the DevTools, but the shift towards a better and more intuitive UI for these things will hopefully make more people see it as less scary.

Below is the measurement of

1*nyojhJ mS0tdhweIm9QJhA

If you are familiar with the network tab, you might see some similarities. The view gives an “easy” to understand the timeline of a page with its requests and Web vitals metrics.
I still believe there is room for improvement, for this tool to become mainstream (like Lighthouse), even though I can’t put my finger on, what needs to be changed.

As everything becomes more technical and digitalized, I believe we (humanity) need to build more tools like this, so we can level the field and have a common understanding of as many things as possible.

These things take time, and a lot of iterations, but I think it would be in the interest of both developers and stakeholders, to be able to discuss more aspects of development without having the same educational background.

News Credit

%d bloggers like this: