Ironically, the page took more than a minute until first paint on an old iPad. (I even restarted the poor thing, thinking the HTTP stack had somehow died.) Please, mind that not everything is evergreen and that there's not much reason from a user's perspective to put perfectly working equipment to scrap just because devs decide to go with newest standards only. (Think green computing, which includes electronics waste. This also works both ways: a robust implementation is more likely to work in a few years from now on a then newer, probably much different browser engine.)
These are useful performance indicators for sure, but I don't understand how these are different than the metrics already built into Chromium's "Lighthouse" page speed audit (the "Audits" tab in the inspector).
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.
Lighthouse is a lab-metric system while Web Vitals is a "real-user-metric" system. Both approaches are valid, and have their pros and cons.
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.
@cramforce nailed it. One thing I'll add.. I would strongly encourage everyone to collect "field" (real user measurement) data for each of these metrics via their own analytics, as that'll give you the most depth and flexibility in doing root cause analysis on where to improve, etc. The mentions of CrUX and other Google-powered tools are not to create any dependencies, but to help lower the entry bar for those that may not have RUM monitoring already, or will need some time to get that in place.. For those users, we offer aggregated insights and lab-simulations (Lighthouse) to get a quick pulse for these vitals.
These are great, but increasingly none of our web app's performance issues relate to any of these metrics.
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?
> 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.)
> (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.
I think those metrics aren't brought up as much in the blogosphere because they are harder to measure. Those metrics will be unique to the context of the app they're measured in. The metrics talked about in the article are ones that can be determined easily in the context that Chromium is working in.
> where's the literature on how those affect user satisfaction?
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.
I believe it, but I mostly hear about how user retention drops off if the website takes more than 1s to load.
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
I hate slow sites and am pretty aggressive about bailing on anything that I consider slow.
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.
>If you require executing javascript to display things you've already lost and your site is already unhealthy no matter what because it's not a website.
That ship has sailed, nobody cares if it's not a "website" as in HTTP only, including 99% of users...
You say “nobody cares,” but I and many people I know and work with do care! I understand your point of view but maybe you should try to understand where others are coming from.
> I understand your point of view but maybe you should try to understand where others are coming from.
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.
> 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?
>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.
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...
Eh. I think you're intentionally making things fuzzy.
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.
>The truth is that modern popularity is based off a narrow subset of shit-tests which are easily duped (Trump passed).
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).
> I don't think quality, or, for that matter, political choices (as in your example), are that simple to judge.
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.
> Popularity is a B.S. metric of correctness, quality, or pretty much anything other than zeitgeist.
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 ;)
Is there a name for that little suggestion box that slides into place, and more importantly is there a way to turn it off? I've trained my self to wait a couple seconds before clicking on links because it's popped under my cursor so many times.
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.
Makes you wonder how much money Google (and sites running ads in general) make due to people doing that. I'm sure quite a few people must accidentally click on ads they didn't mean to clik on due to that shift.
This is cool, thanks for shipping! Is Full / Largest Contentful Paint registering WebGL draw calls? My use case is a single page (up to 4K resolution) that contains a single canvas element and 3D context. Time to scene rendered to user is obviously of interest.
And any prospect for a full featured WebGL inspector / debugger in future?
To be frank, I don't care about a 500ms faster site if I spend 15-20 seconds navigating a convoluted GDPR notice, dodging newsletter prompts and looking for a one-line answer in a sea of ads and SEO filler text.
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?
This seems to be failing the X-Forwarded-For validation on my site. I expect one X-Forwarded-For header entry on my (Heroku hosted) site, but requests from the measure tool [1] seem to have two entries in this header.
>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.
I don't see why you would only have one of those headers. There are use cases for two proxies to operate (think a corporate proxy + your proxy, or a corporate proxy to a privoxy instance to your proxy, a corporate proxy connecting to a data-saving proxy, etc.). Some proxies like to add these headers by default. Duplicate headers are acceptable in HTTP, so this is all perfectly up to spec.
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.
I just loaded a few Google services I use. AdSense takes 6 seconds to load. DoubleClick takes 10-15 seconds to load. Running a speed test on fast.com I'm getting 200Mbps.
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.
Switching from Google Analytics to GoatCounter[0] was one of the best decisions I ever made for my personal site. I hadn't realized that the slowness of GA was keeping me from using it. The UI of GC is so fast that I often check it for fun, even on my phone.
It's not Google that's preaching this. It's Chrome. Sure, Chrome is owned by Google. but at the scale of Google, you might as well consider them as independent organizations.
What Google sites are you referring to and what "do as I say, not as I do" behavior are you seeing? I'm not doubting you, I'm just asking for specific URLs so that I can forward the feedback to specific teams.
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.
Gmail and YouTube were the first Google products I could think of (other than search), neither loads in under a second over WiFi where I have 50Mbps. Not even with a warm cache.
