I just ran their audit to https://mail.google.com, you guys (googlers) need to speed up your websites first, Gmail is terrible slow lately, just saying...
I also find it strange how I can get an A on every other page speed service, including GTMetrix, but get an F on Google's tes(s). Totally useless.
Fixating on the overall score seems like an indication of a different problem.
For example, you can't change the caching behavior of google-analytics.js, and it's usually intractable to split apart your CSS to optimize for above-the-fold content. Oh well, you didn't get a perfect score. Stay practical.
I'd be hard pressed to let stupid things client/managers can do direct how this sort of tool should work. For example, it'd be silly to demand "score inflation" just because your client is unreasonable. Or rather, if a client is making your life hard, I don't think it's the world that needs to change.
What's your solution if your client measures your success by punching their website into https://www.worthofweb.com/calculator/? And doesn't take you seriously enough to listen to you in general?
I'm no lawyer, but I read that as it is not used for tracking users.
(full disclosure: I work at Google, on something unrelated)
Probably to allow for updates and estimate popularity, with low overhead assuming CSS files are small.
> We only [sic] see 1 CSS request per font family, per day, per browser. Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.
I read that as what's written there. It's for tracking. Tracking popularity is still tracking.
Tracking usually refers to tracking users, which as I read the FAQ isn't what it's for.
The script request is to a cookiless domain for performance, unlike the ad request, so there's not even much useful information on that request.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
https://www.google-analytics.com/analytics.js
Google cannot bust this in case of a bug. They can mitigate this by having a loader with built in functionality that always looks out for "is there a newer version" but that has its limitations.
* Faster iteration time for developers: the more often you release updates the faster you can move. If your script has a one week cache lifetime then there's not much point in daily releases and any experiments you run will be really skewed.
* Quicker response to problems: if we push out a bad update that gets past our testing, the TTL we serve it with determines how long that will stick around in browser caches.
(Disclosure: I work at Google, on ads JS, and I previously worked on mod_pagespeed. Not speaking for Google, just myself.)
"Error: 500 from Lighthouse API: Internal Server Error"
Now gmail is slower than most any other website I use regularly. Can't even refresh the inbox in less than three seconds.
I've noticed the same slower by a bit every year pattern with google maps too. I'm afraid to click anything when I have a map open because I know it might trigger a repaint which will cause me to sigh and switch to another tab while it chugs for a few seconds to accomplish this.
I have a vacation auto-responder permanently on on Gmail as well to notify any individuals who hit my old address where my new address is.
edit: Last one because it supports keyboard shortcuts.
>Google's web platform team has spent over a decade learning about user needs. Now we want to make it as easy as possible for you to master the defining standards of web development today.
>Fast load times
>Guarantee your site loads quickly to avoid user drop off.
"Loading Gmail"
>Network resilience
>See consistent, reliable performance regardless of network quality.
"Loading..." (in yellow at the top, after clicking a search result. Indefinitely.)
(some other non-quoted parts are OK)
>Accessible to all
>[Build] a site that works for all of your users.
You can see this yourself here: http://mail.google.com/mail/h/ (direct link to html view. you have to already be signed in for this link to work.)
Side note: I'm sure you would have mentioned it, but you don't happen to work at Google on the new Gmail front-end, do you? (Since I could see someone who is, trying to deflect blame for their current bugs by "blaming the back-end".) Just want to make sure...
I dig google and its products but oh wow is this bug frustrating. Hope it’s fixed soon.
Recently I started using the html only version of Gmail because for my user case is faster than the web app.
Wait, was web.dev built by the Gmail team? I always assumed Google was bigger and more complex than that?
If there's any other decent page speed assistance I'd love to see it.
In fact, it wouldn't be hypocritical even if the authors of web.dev themselves worked on a site that did badly.
It is, after all, a tool. It's not a declaration of superior intellect. It's not an article of condescension. It's a tool.