Web Vitals: essential metrics for a healthy site
blog.chromium.org
blog.chromium.org
Is the difference now that they will be more heavily weighed in search engine ranking? The article wasn't super clear on this, and the explanatory links seemed to push towards drinking a lot of Google kool-aid (eg. to measure the Core Web Vitals you must use Chrome UX report, and to do that you must use Google BigQuery, and to do that you must create a Google Account _and_ a Google Cloud Project. Wow.)
On closer inspection this whole thing is just a thinly veiled advertisement for GCP. No thanks.
Generally, lab metrics are convenient because you can run them whenever you'd like including before deploying to prod. But they can never tell you the ground-truth of what is really happening out there that real-user-metrics provide.
E.g. the FID metrics only make sense when someone actually interacts with your site. Lighthouse cannot know when people would interact and thus cannot calculate the metric.
It is ironic that the vast majority of these performance issues are caused by render-blocking and CPU-sucking JavaScript, and so the recommended approach is to install yet another client side JS library (https://github.com/GoogleChrome/web-vitals/), which appears to only work in Chrome, and then use the library to post client side performance data to Google Analytics (though to be fair it could be any analytics).
"How badly are all your JS libraries slowing down your page? Find out with this one weird JS library!"
This seems like one of those things where if you get to the point where you need this, you're already in too deep.
No, you just need this bit of javascript: https://github.com/GoogleChrome/web-vitals
Memory leaks, slow typing, UI interactions like opening a modal that shouldn't be taking 8s+, where's the literature on how those affect user satisfaction?
That's right there in the post. Google calls these things "input delay." One of the three primary metrics called out in Google's post is FID, "first input delay," which is the delay on the first user interaction.
(Subsequent input delays are also bad for users, but subsequent input delays are usually only as bad as the first input delay.)
I'm not sure about this statement. It sounds reasonable but I can't recall seeing any research about FID being a proxy for all input delay throughout the entire duration of a session. I would hypothesize that optimizations that improve FID would also tend to improve input delay in general. My main message here is just that I haven't seen that research.
It's not a matter of first vs rest but observation that input while the page is loading is, often, where most of the egregious delays happen: the browser is busy parsing+executing oodles of script, sites don't chunk script execution and yield to the browser to process input, etc. As a result, we have FID, which is a diagnostic metric for this particular (painful) user experience problem on the web today.
Note that Event Timing API captures all input: https://github.com/WICG/event-timing. First input is just a special case we want to draw attention to due to the reasons I outlined above. That said, we encourage everyone to track all input delays on their site, and it's definitely a focus area for future versions of Core Web Vitals -- we want to make sure users have predictable, fast, response latency on the web.
As someone else mentioned, it seems like all the issues you mentioned ultimately create user dissatisfaction because of input delay. In which case FID seems like it'd be a good metric for you to target. I'm not sure about the claim that if you improve FID then all input delay will be reduced for the entire duration of a person's session with your site, but I imagine that FID and general input delay are directly correlated. This is just conjecture however and is not a statement backed by research.
Here's a summary of some general research on how users perceive input delay: https://developers.google.com/web/fundamentals/performance/r...
(Tangentially related) The new performance.measureMemory() API may help you correlate memory leaks with business metrics: https://web.dev/monitor-total-page-memory-usage/
And while I believe other types of slowness make users unhappy without seeing the literature, the people driving our priorities don't see the $ impact at all
But speed is a visitor's feature, not a benefit. The benefit (to the web site operator) of an ecommerce site is $ spent by visitor.
So for example yes, the Amazon site feels slow and bloated, but they've been doing live A/B testing for over 20 years and I'm pretty sure they don't care about speed unless it affects conversion; they'll be happy to cram something in even if it slows the site down, if it increases revenue.
That ship has sailed, nobody cares if it's not a "website" as in HTTP only, including 99% of users...
Can you make an argument for it? It kind of feels like a movie critic trying to explain why the Transformers are bad, even though they still rake in billions. If the Transformers changed to make the critic happy, it at best would have no impact on the billions, in all likelihood it would cause a regression, and so the critic needs an incredibly compelling argument.
Popularity is a B.S. metric of correctness, quality, or pretty much anything other than zeitgeist.
It blows my mind that people still argue there is causality between quality and popularity. Certainly, there's correlation sometimes, but something does not need to be quality to be popular, nor is quality always popular. I mean, Van Gogh wasn't recognized until death. And you saw the 2016 US elections right?
Yes, but "quality" is a fuzzy and personal metric in many domains...
Or conversely, "quality" can be defined as "popular with the critic type" in these domains - so it's still just a kind of popularity metric...
If you have a bunch of Bowerbird watching the movie, it better have the color blue to be popular with them. We can reduce their "shit-test" list to something simple which obviously overlaps minimally with what is a reasonable definition for quality.
I'll yield that the Transformer movies do have phenomenal CGI, and that people who like them are in fact discerning of the quality within that. But this is just one dimension of "quality," and I highly doubt the critic is unaware of it.
The truth is that modern popularity is based off a narrow subset of shit-tests which are easily duped (Trump passed). Meanwhile there are many critics who aim to have a much broader and accurate shit-testing system. Some of them get up their own ass about trying to be above common shit-tests, and in the process they debase critics as a whole. All shit-tests matter.
But the point is that most people are really, really easily hackable and calling something that gets through their defenses a "quality hack" is lame. It's like hacking peoples wordpress sites from 2000.
I don't think quality, or, for that matter, political choices (as in your example), are that simple to judge.
E.g. Trump might have won, but not necessarily because people were "duped", but because they was not much better on offer -- it was either a Rob Schneider fart movie (Trump), or a pretentious emotionally-dead tone-deaf to many issues Hollywood oscar-bait (Hillary).
Of course not. Every judgement is ultimately a failed attempt at omnipotence. But we try anyways, and there is such thing as progress. We can get closer, especially relative to each-other.
There's a great joke that the only probabilities humans believe in are 0%, 100%, and 50%. Basically anything that isn't certain is likely going to be treated like 50% by most people. It seems to be central in "equality of opinions," or "my ignorance is just as good as your knowledge."
To summarize, I think the following is a fun reductio-ad-absurdum argument, but ultimately not true: "There is no 100% accurate way of measuring quality, therefor all means of measurement are equally meaningless."
If it was true, there would be no point in symbols or abstractions of any sort.
In the case of transformers it's also a measure of money made, which, being incredibly pragmatic here, is also the point of most website people are paid to work on.
I'm not trying to say that all other measures don't have value or anything like that, I'm just trying to be practical in terms of the needs and goals of most modern websites. I'd much prefer every website was made "right", but "right" is nebulous and expensive.
In the language of your analogy it would be "Transformers are unethical!" Our collective obsession with making billions is ruining entertainment media / the Internet / everything unfettered capitalism touches ;)
Fact is, applications and websites mostly exist for commerce.
Especially in search interfaces.
I don’t have the energy to continue, so I’m left with that classic software dilemma: good underlying technology, or good UI.
This happened to a colleague of mine not that long ago and I told him the trick is to report just about anything using the feedback tool and observe the most crazy bugs disappear in less than an hour as you get reassigned to tve A group ;-)
Another educated guess is a plug-in. I might have seen plugins that seems to optimize for ad click through by adding elements to move the ads just under yiur mouse pointer.
And any prospect for a full featured WebGL inspector / debugger in future?
I would define essential metrics very differently:
- How fast can the users find the answer they are looking for? - What percentage of user interactions benefit the users? - How much information does the website collect about the users?
Example log entry:
2020-05-05T23:00:07.144973+00:00 heroku[router]: at=info method=GET path="/en/" host=redacted.com request_id=a0c8605f-e67a-4b48-9538-c6bafebaaaaa fwd="107.178.238.42,66.249.84.103" dyno=web.1 connect=1ms service=4ms status=400 bytes=294 protocol=https
>If a request goes through multiple proxies, the IP addresses of each successive proxy is listed. This means, the right-most IP address is the IP address of the most recent proxy and the left-most IP address is the IP address of the originating client.
In this case, if your reverse proxy is adding its own header, it should be stripping away the other X-Forwarded-For headers if you so wish, or have the application pick the appropriate header if you wish to receive all of them. This sounds like a misconfiguration issue on your website to me.
Physician, heal thyself.
Without question Google makes the slowest and least responsive sites I use. It's like the 600lbs man giving tips for staying in shape and living a healthy lifestyle. When they have a nearly unlimited budget and access to some of the best engineers and infrastructure on the planet, and they can't practice what they preach, it's difficult for me to listen.
Google.com is 34 requests and 2 MB resources. That page contains an image and an input box.
Original web.dev they rolled out was something like 15 megabytes in size (thankfully, they fixed that).
Google domains is 1.3 MB of JS for what is essentially a static site.
Their recent announcement about some advanced video compression they did (I immediately forgot, it was on HN). 55 MB with a 3 second video on it.
Material design. Just the front page is 3 MB of resources. Of them, 1.3 is Javascript. For a static page.
I can agree though that they have very slowly been getting better with some of their public properties. When we start talking about internal/private/customer-oriented pages (GCP console, GMail that immediately come to mind), they are just horrendously awful.