This reads to me as an attempt from Google to further balkanize the web. This looks a lot like the "blue bubbles" effect from Apple iMessage.
Did Google run out of actual features to implement? How about reacting to real user concerns such as controlling the privacy of their personal data on the web? Rhetorical question, I know...
Speaking as a real user, let me assure you that website speed definitely falls under real user concerns. I don't know how much I'd use this indicator, but loading speed matters to me. Loading speed matters a lot.
This won't win me back from Firefox, but I don't consider it a bad move.
If you are against user tracking, great, you've got many on your side.
But what loads fast is web pages that are made to load fast. If they are able to load fast despite user tracking (which is entirely possible), then it is simply a different issue, and this should not be flagging them as slow. If they are flagged, it should be by something different.
If Google is going to implement this (which I support in general because so many sites are painfully slow because there aren't enough incentives to make them fast), what they should be measuring is speed of loading, independent of whether it is slow because of user tracking, slow because the developers do other obnoxious stuff (fill it with click bait images, have videos autoplay, etc), use frameworks sloppily, put too much contents on the page, have a high res background image or video, have a crappy server or use a slow backend language, or whatever it is.
While Google does a lot of user tracking, I think the normal way they do it is actually pretty fast. Fault them for user tracking, but if they are able to allow site owners show Google ads without slowing down the page load significantly, don't lump them in with all these other ones that both track users, as well as make the site a painful user experience.
When I had to use gmail for work I switched back to the plain html interface. It was startlingly fast
As far as I could see all the complicated front-end stuff added zero to the user experience. Ok, so yeah, you needed a page load to view a message or whatever, but it was quick and hardly noticeable. All they needed to do was freshen up the stylesheet and call it a day. But, I guess, all those developers and product managers needed something to do in between building a new messaging app and killing the previous one.
Walled gardens and proprietary software can allow for fantastic user experiences in a way that open platforms often cannot match. However, I feel focusing on the user experience misses the main point - the web is an open platform, and this is an example of Google exerting an authority that many may not feel comfortable with.
Because the criteria will inevitably be biased towards technology and techniques that favor Google, Chrome, AMP, etc. If you trust Google to be an unbiased arbiter of objective measurements of website efficiency, you are giving them a lot more credit than I would at this point.
Visit an AMP page in Lighthouse and you won't see an especially good score. Lighthouse doesn't special-case AMP or pick metrics that would make AMP look good.
Because Google is the decider of what constitutes "slow"? You have a single organization deciding what the threshold is between slow and fast. And, they also have a Google-approved solution (amp) that I'm sure they will tie into the recommended actions for "slow" pages.
I'm not saying it's a walled garden (that's a more extreme situation on the continuum between open and closed), I was just using the phrase to illustrate my point that the end-user experience isn't the only factor to consider.
In the United States, the role of a central bank is to manage two measures: inflation and unemployment.
The US Federal Reserve Bank does not measure inflation or unemployment. Rather, the US Department of Labour, an independent organisation (and a branch of government rather than a freestanding entity) computes both measures.
This is the principle of division of responsibility and measurement or judgement. You cut, I choose.
Google are both measuring, and rewarding, website performance, as well as designing and distributing the principle tools that benefit by both choices. That's an extreme locus of power. And, history shows, generally a Bad Idea which Ends Poorly.
>Google are both measuring, and rewarding, website performance, as well as designing and distributing the principle tools
Also given their market share as a search engine, they also get to decide which websites you will be able to "discover" additionally incorporating their performance metrics into their website ranking. So not only a website will get a "slow badge" but will also be downranked into oblivion.
If Google didn't have a long history of this sort of thing (interpret that as you may) the open web would have lost the battle for mainstream users to the proprietary platforms long ago.
Then demand for smaller sites, nothing will make for a faster web if web pages are larger than operating systems from just a few years ago. do you know how ridiculous it is to have web pages that are tens and hundreds of megs?
The issue is not with the browsers, it's with the damn stupid sites out there. 3G is pretty much useless out there, let alone 2G.
There is no paid site that matches the quality of HN. Same goes for most social network: What gives them value is contributions, and contributions only seem to happen if the access is free. Otherwise you don’t reach a high-enough density of people.
This is an attempt by Google to influence the bloated websites out there, rather than a browser feature intended to attract users. It's probably mildly helpful as a user to know if a site is slow (as opposed to it just being slow for you), but it's a big incentive for a website owner to speed up their site if this badge of shame appears it for a majority of users.
Gmail scores a 50% on Google's own PageSpeed. And that's just the login screen. If Google can't even meet their own metrics and standards then they have no place telling other people what they should be doing with their websites.
> If Google can't even meet their own metrics and standards then they have no place telling other people what they should be doing with their websites.
The fact that they are failing their own if anything, shows that the tests don't discriminate. It's defeatist to say that we shouldn't strive for faster websites if some webpage fails. I really like how dumb f*s making 40MiB pages are now finally punished.
Yes, but Gmail doesn't really have to compete in Google Search, does it? So, in their eyes, it's OK for Gmail to score low because it has its own link in basically every navigation toolbar/header Google owns. This won't improve the speed at which Gmail loads, whereas all non-Google websites will have to improve their speed.
It's not that Gmail has a dominant position and so doesn't need to care about its rating - Gmail is an app not a page and it's less important for apps to load quickly than pages. Apps tend to be long lived and so a slow startup time is tolerable, whereas one is constantly opening new pages.
That is to say, I don't think e.g. Trello would really care if their site was "slow to load" either.
You might be surprised how fast web pages load when the browser you’re using blocks the tracking scripts, especially on a mobile device. Brave runs on iOS and Android; the iOS version with the Brave Rewards wallet is expected to be released imminently.
You might want to take a look at Brave, which uses Chromium underneath, has Tor built-in, is compatible with Chrome’s plugins and even has a business model based on paying people to view ads only if they opt-in: https://brave.com/features/
Do you really need your browser to tell you a site is loading slowly? You're staring at the screen; don't you know if it's slow just by existing and moving forward through time?
Or is this just a way for Google to kill off the progress bar, too?
If I'm staring at the screen waiting for a page to load, a loading indicator can help me figure out if I should keep waiting longer or give up. That's very useful!
If this gets site owners to work more on loading speed so they can get a badge that's great. I used to work on mod_pagespeed and one of the big problems was that publishers just didn't care that much about loading speed.
Based on what this feature is and the scenario you described, I think it may disincent site owners from speeding up slow sites. At the moment, a user doesn't know if a site will ever load. If Chrome reassures that "this site usually loads slowly" they may stick around since they are then reassured that it probably will eventually load, it's just taking a while.
Maybe users will respond that way, but that's still a good outcome. Giving users a better idea about what to expect so they can make more informed decisions? Great!
No. I mean a badge that pops up for Google products warning you that they may send your personal data to Google even without any user interaction, when the user does not reasonably expect this. What happened to "Giving users a better idea about what to expect so they can make more informed decisions"? I guess profit has a stronger scent and we can all assume that Google is tricking users with those "slow loading page" warnings just to get more for themselves. I feel that you are being willfully ignorant about this.
> Both Android and Chrome send data to Google even in the absence of any user interaction. Our experiments show that a dormant, stationary Android phone (with Chrome active in the background) communicated location information to Google 340 times during a 24-hour period, or at an average of 14 data communications per hour. In fact, location information constituted 35% of all the data samples sent to Google.[0]
Based on my understanding, Google would be communicating _why_ the site is loading slowly (the network, or the site itself), which isn't something that would be immediately obvious.
Memory size is a problem, too. Even a small amount of Javascript can allocate a ton of memory. I'd love to see a more memory-efficient language replace JS, then a reasonable but lowish memory limit put in place. Say, 8MB, which still seems generous to me.
The only trouble is you'd have to find some way to keep developers from using the DOM as extra memory. But the capabilities of Web scripting languages, outside perhaps some very strict and explicitly enabled on a case-by-case basis sandbox, really ought to be limited more anyway.
JS is not necessarily heavy. For example, the Espruino is a platform running JS on microcontrollers with less than 100KB of RAM: https://www.espruino.com/
If their speed assessment works as "great" as their "mobile usability" tool works, i doubt their indicator will be actually meaningful. YEah speed matters a lot , but it's self-correcting. If a website cannot load after a minute on a spotty cellular connection , i ll just close the browser and they lose the impresison
It reads to me as an attempt from Google to further shame people into following better practices, like when they started factoring HTTPS into search rankings.
I think the principle is a fine one (though it is a bit odd considering the web's main source of slowness is ads/tracking tech, and... that's Google's main business). But in practice I'd bet that - like most of Google's broad-strokes efforts - there will be many edge cases/outliers where people get penalized unjustly, and there won't be an appeals process.
> further shame people into following better practices
"Better" as prescribed by who? At this point, I'm under the impression that if you're not implementing AMP for content, Google is going to rank you lower and now publicly shame you to users. They _say_ this is not the case, but it's impossible to ignore now that they're introducing naming and shaming. It just seems like features way outside the scope of what a web browser should be providing to users.
Editing to add my other thought:
I've built websites that routinely score horribly on Google's proprietary PageSpeed Insights despite fixing everything within my power (usually Google's own analytics scripts score badly), but also score very high on every other reasonable industry test of similar nature. It's hard to convince me that they alone should be an arbiter for this type of feedback given to users.
I believe you, obviously. I have historically received drastically different results between, for example, web.dev / Lighthouse and PageSpeed Insights with the latter outputting a very low arbitrary 'rating' or 'score' and the former providing results I would expect. Like a lot of efforts at Google, things seem duplicated. As an outsider, it is a frustrating experience catering to Google's performance ideals because the tools and 'best practice' positions do not seem to be unified in one place.
I wonder if you might have had a bad experience with the old rules-based PageSpeed Insights? It wasn't as good as the current one, being more of a checklist of "have you done all these things that usually help" and not "we loaded the page, computed metrics, and this is how well it did".
Yep. Looking at it cynically, this could be a way of playing hard-ball with web admins: "if you want to keep using Google stuff, and you don't want this badge of shame, you better use AMP"
This is Googles blueprint to eradicate apple. They want Web apps to dominate because they already have a standing there and apple has a large marketshare in native apps.
"Did Google run out of actual features to implement?"
That question is kind of coming in at the wrong angle. Google has identified the speed at which web sites load as a problem, and have determined that is a problem worth their while to try and solve.
The problem is that it's all the tracking and advertising that's the cause of the slow loading and Google, being as that tracking and advertising pays their bills, can't solve that as the fundamental problem, so they're doing a very odd looking Twister-Limbo set of actions in trying to reframe what the problem is: speed of page loading.
Google are attempting to treat the symptoms, because they profit from the cause.
Google needs to solve the speed symptom before someone else solves the ad and tracking cause (ad blockers, PiHole, etc.) in a more fundamentally non-technical-user accessible way.
At least based on the picture, the 'slow' badge should only show during the TTFB, ie. before any paint occurs. Since Google Ads loads after the paint websites likely won't have issues of mis-labeling.
The vast majority of people that I know who don't use adblock do so because they are A) afraid that it will slow down their web browsing, or B) believe that it magically generates money for content creators.
Advertising is a contributor, but it's far from being the cause. AFAICT there are five causes, namely slow DNS lookups due to inappropriately low TTLs, a lack of caching both serverside and clientside, page bloat, an overdose of javascript and an overdose of tracking/advertising (which contributes to bloat and javascript).
Making a Rails site pleasantly fast was more work than it should've been. Rails didn't make it easy to cache page components, didn't make it easy to cache the entire page either, made it easy to inadvertently wait on the database. And here's the key, this doesn't seem to be regarded as a big problem. The rails developers and users don't regard slow speed as a big problem. Is that unusual? Do Django, Magnolia, Magento have a different culture? I haven't noticed (but I might not). Assuming not, the root cause is an inattention to making sites pleasantly fast, and that inattention has simply allowed advertising to have the same problem as the rest of the site's software.
I will agree with you that Google has killed the web, news groups, federated chat, and so many other things, but I find the term "balkanization" both very disrespectful and at the same time a bad fit for describing Google subverting nearly all communication channels.
I feel like this will get a lot of flak from HN users, but I think this will overall be a benefit to the user experience on all browsers, not just chrome.
I used to hate AMP with my guts. But to be honest, usually when I tried to avoid or loaded the site instead of AMP, I get presented with a worse experience in a bloated web-site, whereas when I click on the AMP version, it loads immediately. So now I don't care anymore. But google is not my main search engine, so I less very little of it.
I'm thinking the same, this willbe used somehow to push more users into Google's walled garden.
Amp is like ten times as slow for me.. Firefox on android, a bug in amp makes the pages not scrollable. Have to press the tiny little icon in the top right, then again press the url, and then wait for the page to load an additional time.
This will give developers leverage to ask for time to optimise, upgrade, and improve things they are not normally allowed to work on, as it will raise the discussion to the level of managers and the general public.
However, do you think more could be done to make the default MySQL/PHP type configurations faster out of the box? If it is possible to speed up the default config of most websites on the internet, perhaps there is an easy win to be had.
> However, do you think more could be done to make the default MySQL/PHP type configurations faster out of the box?
I'm pretty sure that most slow websites aren't slow because their server-side rendering takes a long time. This seems to be mostly a front-end oriented thing (especially directed at pages that load MBs of JS); basically if the page doesn't adhere to all the front-end optimisation guidelines.
The slowness described in the article isn't jank, but time-to-initial-load. Conceivably the initial client-side render could take a nontrivial amount of time, but in the vast majority of cases - just like for server-side rendering - it isn't a deciding factor.
The real deciding factor is the amount of dependencies that have to be loaded. This includes JS, but usually the JS for ads/tracking is far larger than the JS for the actual UI, even on fully client-side-rendered sites.
PHP and MySQL are pretty fast out of the box - and have been for a couple decades (a single server was well into hundreds requests per second by 2000).
What’s slow are the frameworks on top of them, and a lot of that is going to require big changes since things like the WordPress plugin world or most of the JavaScript world have not had a great culture about monitoring and optimizing things. Simply moving this into the category of problems you can’t ignore would be positive - along with tracking data usage for mobile users on metered plans.
I hope they roll out good monitoring tools for website owner for these features - i.e not a tool to test your site but a tool to tell you what google reports to it's users about the site. Otherwise you can be fooled by running lighthouse against your local server and never see the "this site loads slowly" message...
I'm going to be a little nitpicky here: This would be grammar checking, not spell checking. "Slow" is spelled correctly, it's just not the right word (adjective vs adverb).
This also seems to still be in the experimentation phase and is not released as far as I can tell and may never actually make it into Chromium based on:
> In the future, Chrome may identify sites that typically load fast or slow for users with clear badging. This may take a number of forms and we plan to experiment with different options, to determine which provides the most value to our users.
Regardless, I agree. This probably should've been caught early.
Your comment about "ad-words" made me think: could Google sell ad space on these "slow site" pages? Site X might jump at the chance to pay Google to advertise its service on site Y's slow site page. I'm only half-joking.
If the progress bar is green and a site is loading slowly, you're having an anomalous experience, be patient? If blue, expected, maybe give up and don't visit again? That's my impression.
I think this is more for project managers and site owners. These days we’ve become numb to the load speed, but if your browser tells you “dude your site is slow” there’s a chance the developer will get a call and money to speed it up.
You don’t want your customers to see that badge while looking for your Product X 3000 Max.
Google Capone: "Hey, nytimes.com, your site loads awful slow. We're gonna have to put this badge of shame on it for everyone to see.
Now, if you just dumped your other ad networks and ran everything through us, I bet it would be load much faster and that badge might magically disappear..."
> Now, if you just dumped your other ad networks and ran everything through us, I bet it would be load much faster and that badge might magically disappear...
My experience with everything google has touched lately suggest that this wouldn't improve speed any. Gmail and youtube make continental drift look speedy and even the search page takes 1.4MB and takes over a second to load for me (maybe corporate network issue), that's approaching the size of doom to display a dozen links.
Google doesn't have any moral authority when it comes to bloat.
Edit - for reference HN takes about the same time to load, but that has to cross the pacific ocean whereas google supposedly has local data centers.
There's a big difference between "done loading" and "appears to be done loading". Google is reportedly very cautious about the latter, and pulls some hijinks to appear faster than it is. Frankly, I'd be happier if more sites paid a similar level of attention.
That said, if your search page takes over a second, you're right, it might be an issue with your network.
I think the point being made is that it's no longer actually about the speed, it's about the 'badge of shame'. The analogy being used is accurate, in that 'protection money' isn't, and was never, about protection.
The only PC where I saw Gmail being fast was a Ryzen 9 3900x build, I suspect that if Google devs were given shittier PCs they'd build faster products that would appeal more to the average user.
I have a Google-issued corporate workstation with 64 GB of RAM and 12 cores. Gmail is really really slow. Like so slow that I if I have to refresh it I'll go get coffee. But I'm on Firefox, and so "I Am Not The User" and all that.
Even better, just run Gmail in basic HTML mode. This way you can even open emails in their own tabs. Sure, you lose a bit of functionality, but its well worth the tradeoff, in my opinion.
Part of the problem is that they place high importance on the first contentful paint (aka FCP) above all else. They're not very much looking at how it performs overall, mostly just how long it takes for a user to see the first bit of content. If that were a bit of text that said "loading" with a spinner that goes for a minute or two, they may consider that fast.
(Note that the table gets cut off on narrow mobile screens... I’ll file a bug)
FCP is 20% of the score. The other metrics capture different milestones in the loading experience. For example Total Blocking Time is intended to bring awareness to sites that may look complete but can’t respond to user input (because the main thread is busy running JS).
The metrics overview that we just launched provides more detail about how our metrics were designed to capture the end-to-end loading experience (or at least that’s what we’re working towards): https://web.dev/user-centric-performance-metrics/
So in the case of your site-that-just-loads-a-spinner example, yes it might have a good FCP time, but it’s LCP time probably wouldn’t be that good, and therefore the overall Performance score would be mediocre.
Long story short, I don’t think it’s as easy to game a good Performance score as you might think
Actually one of the things that Lighthouse (Chrome's speed test tool) complains about a lot is some of the things that are a result of using Google's AdSense.
The way that the Google Search unit gives preference to Google AMP unit in its mobile results? Yes, I suppose it's a good sign that they don't also give that sort of exemption here, but I would consider that expected, not praiseworthy.
We mention that ad scripts are a common type of problematic 3rd-party resource but we use the phrase “3rd-party resource” because there are lots of other common problematic scripts, like A/B tests, social media widgets, and analytics scripts.
This sort of basic advice (use browser features to defer loading, and plead with the masters not to ask for so much JavaScript) is obviously already considered by the HN audience and so this link is basically useless.
I sincerely doubt 100% of the HN audience always considers those things.
You might think some of those things are basic, but that doesn't make them useless.
This kind of lack of empathy for new learners can make it incredibly difficult to teach concepts to those who don't have as much knowledge as you may have.
How does Google works internally between teams on this kind of issues? For instance, do you work with people developing Google apps sometimes? Because it seems that they've gotten slower and slower as time goes: for instance, if YouTube was a porn tube, it will be dead already because it's much much slower than the competition.
Our long-term goal is to define badging for high-quality experiences, which may include signals beyond just speed. We are building out speed badging in close collaboration with other teams exploring labelling the quality of experiences at Google.
Exactly what does "high-quality experiences" mean? Penalize sites with bad colors? Sites that are artsy and an algorithm can't understand? Sites that have been repositories of information for longer than Google has been around? Sites that don't meet Google's worldview? That disagree with Google's politics?
While I appreciate fast loading sites as much as anyone, there's something I appreciate even more: getting to the content as fast as possible.
It's becoming increasingly common to have all sorts of pop-ups blocking a big part of the screen at best or adding an overlay across the entire body.
If only I knew that my click would result in that kind of monstrosity I wouldn't have clicked in the first place. So maybe it would be more useful to show an of how many things we need to close before we get to the content. I think that something like this would also help get us to "a faster web".
They say "Our long-term goal is to define badging for high-quality experiences, which may include signals beyond just speed. We are building out speed badging in close collaboration with other teams exploring labelling the quality of experiences at Google"
I'm worried that their definition of "high-quality experiences" will be the same one as typically used in UX on the web - i.e. how much money did the users ultimately made the site, and not whether they actually had a good time.
I understand a lot of the distrust of Google her one HN, but I also don't think that would be their style. To me, the sites done with Google ads aren't the ones that are the problem, then tend to load fast and not put a bunch of crap in your face.
Yeah they track you and such, not denying that or supporting that, but Google generally pushes back against the sort of bad experience you find at so many sites.
So many sites load 8MB of garbage, often from dozens of domains, just to display 8KB of text. Then as soon as you try to start reading, an obnoxious pop-up window appears, demanding that you sign up for their spam list. These are anti-patterns that need to go away.
But so far, nothing's been done yet. This is kinda weird to me because one of the reasons why Firefox came to power (and took over a bit chunk of IE's market) was that it had a pop-up blocker. I don't understand why they aren't doing more to block inline pop-ups now.
Presumably a site that is using the dark patterns you've described would have a low SES. Although if you're interacting with the site in order to get past the ads I wonder if that would distort your SES? Then again, if the site is doing annoying things, I'd probably bail quickly, so maybe SES can work after all...
Disclosure: I work on Google Web DevRel. I don't know if there's any plans to incorporate SES into this badging initiative. I was just reminded of SES last night because Periodic Background Sync API uses it [1] and it seems relevant to this problem.
Install NoScript. The initial whitelisting period is slightly bothersome, but once your common sites are whitelisted, it makes browsing the web _way_ more pleasant. No more fucking "give us your email!" and "this site uses cookies!" popups. It even works decently on Firefox for Android.
Pages are made of 30 sites, more. This is what makes the experience shit, and Google are bang up responsible. The architecture of the web did not, and does not, include this - the business model that is sustained by it exploits the web, it does not support it.
There's a concern over pushing AMP & their ads. I totally get that, but so far the recommendations that they link to aren't directly related to either:
% curl https://web.dev/fast/ 2> /dev/null | grep -I amp
Terms & Privacy
</a>, and code samples are licensed under the
To me this is better than amp - give me clear messaging around a site's performance rather than mandating a platform that gives the site less control. I certainly worry that there's the potential to abuse this, and I also wonder if Google's own sites (i.e. amp pages) will be biased. To their credit they're showing one of Google's own pages as being slow in the example, but I'd be interested in seeing a 3rd party analysis of what pages are considered slow and which aren't.
Another part of me worries that this will lead to a cobra effect[1], where people optimize a page's first load so Chrome says the page is fast, while withholding the main content of the page for a delayed load, leading to even more site bloat. Identifying when a page has actually loaded will be tricky.
See my other comment about how our metrics are designed to capture various milestones in the loading experience. I think it’s already harder to game a good Performance score than you might imagine, and it’s only going to get harder over time as the web platform collectively gets better at metrics: https://news.ycombinator.com/item?id=21511477
“ Our long-term goal is to define badging for high-quality experiences, which may include signals beyond just speed.“
My speculation is that they are gearing towards web moderation. Tag sites that don’t agree with their world view as “potentially harmful”. This could make an average chrome user immediately balk at opening the site and reading the content.
Before you downvote my comment explain why the above scenario is not plausible.
Google search has defined itself by being the way people access the web, and already has heavy antitrust pressure put on it but the EU for related reasons. Extending that would go against their stated world view, and more importantly raise even more regulatory concerns.
This situation differs from eg. YouTube because they do not themselves host the content, and are not subject to copyright laws related to it.
Also: Google is made of human beings who have already protested against, for example, censoring Google within China.
The best way to have a faster web is to get rid of Google Analytics, DoubleClick, AMP, "web assembly", WebDRM, ECMAScript (and all derivatives), and go back to only loading text and images from a blind server to a user-agent entirely defined by the wishes of the specific user.
But all the stuff that makes the Web slow and pointless to use is how Alphabet makes money.
So as long as you drink the Google-Aid, you're doomed to a slow web of garbage.
Bingo. We patted ourselves on the back for killing the worst annoyances of the web (pop-ups, terrible Flash menus that were always some different, cute thing for every site, big, slow, Applets—god, those would feel responsive and light compared to even a "lean" modern "Web App") but kept a scripting language with enough power to re-create all of that, and worse. The fix is getting rid of it. We won't. Web UX is gonna generally be trash until we get rid of or reign in (esp. remove ability to make requests without user interaction, and remove ability to listen for most events) Javascript. Which, again, won't happen. So Web UX—in practice, as seen in the wild, not what a developer may make to demo light web development or what certain niche sites may do—is doomed to be terrible.
Webmail was terrible back when every single click required a fetching a new page load. Even on a reasonably fast DSL connection, JavaScript Gmail is noticeably more snappy than HTML Gmail.
Pre-ajax online maps? Almost unusable. I certainly wouldn't want to return to those days.
Yes, because you're asking a client for text and images downloaded from a server to do things it was never intended to. When you start employing torturous misuse, you're going to find the tool unsuited to the job. You can use a pipe wrench as a
makeshift hammer, but a sledgehammer can't tighten a nut (more than once).
Use an email and newsreader for email. Use a full mapping suite to download specialized map data. Don't force a web browser to shim into those niche jobs.
Old adage I learned with computers: Do One Thing, Well. That's what each program should be. One thing.
Yeah, pretty much. If web sites would stop stuffing these giant js frameworks pages + 3 trackers + 3 ad networks into all page we could be using like iPhone 4 now.
One of the regular complaints I've pushed against AMP is that it's a hamfisted way to address page speed. Search placement should be determined by generic speed tests, not by forcing developers to use Google's technology.
This looks to me like a positive effort. I'm not thrilled with overlays like this, and I'm not thrilled with baking this kind of stuff into the browser. It feels over-engineered and weird.
But, I think it's a better direction than AMP.
There are a lot of ways this could go bad, but very cautious thumbs up from me.
This kind of effort sounds great, but the issue is that Google has already spent their goodwill on improving the web in this area. Who can trust the company to implement this fairly? Will Gmail get a “badge of shame” (it surely deserves one)? Will websites that are fast but don’t use AMP or the new Google hotness be ranked as they should? There are a lot of questions that I’m sure many have already answered in their head based on Google’s past efforts.
FE devs don’t care about end users. Their sites are slow to load(TheVerge.com), are absolute trash to use (TechCrunch.com) and display an utter lack of concern of compute resources(Lifehacker.com - let you phone idle on this page a few minutes and feel how hot it gets).
FE devs want to be taken seriously, but they refuse to learn the lessons the rest of us have already learned.
If FE devs would get their crap together we wouldn’t see posts about Google trying to wrest as much control as possible away from them.
I have only my anecdotal experience, but when I did full stack work at two large employers HN readers would definitely recognize, we had some really talented developers, and nearly every poorly performing part of a page was dictated by a product owner.
The business can't easily and explicitly monetize "fast" to the same degree it can bloated features and ads/tracking.
226 comments
[ 1.7 ms ] story [ 243 ms ] threadDid Google run out of actual features to implement? How about reacting to real user concerns such as controlling the privacy of their personal data on the web? Rhetorical question, I know...
This won't win me back from Firefox, but I don't consider it a bad move.
But what loads fast is web pages that are made to load fast. If they are able to load fast despite user tracking (which is entirely possible), then it is simply a different issue, and this should not be flagging them as slow. If they are flagged, it should be by something different.
If Google is going to implement this (which I support in general because so many sites are painfully slow because there aren't enough incentives to make them fast), what they should be measuring is speed of loading, independent of whether it is slow because of user tracking, slow because the developers do other obnoxious stuff (fill it with click bait images, have videos autoplay, etc), use frameworks sloppily, put too much contents on the page, have a high res background image or video, have a crappy server or use a slow backend language, or whatever it is.
While Google does a lot of user tracking, I think the normal way they do it is actually pretty fast. Fault them for user tracking, but if they are able to allow site owners show Google ads without slowing down the page load significantly, don't lump them in with all these other ones that both track users, as well as make the site a painful user experience.
Google lost a ton of good will by making Gmail a laughably bad experience on load.
As far as I could see all the complicated front-end stuff added zero to the user experience. Ok, so yeah, you needed a page load to view a message or whatever, but it was quick and hardly noticeable. All they needed to do was freshen up the stylesheet and call it a day. But, I guess, all those developers and product managers needed something to do in between building a new messaging app and killing the previous one.
I'm not saying it's a walled garden (that's a more extreme situation on the continuum between open and closed), I was just using the phrase to illustrate my point that the end-user experience isn't the only factor to consider.
The US Federal Reserve Bank does not measure inflation or unemployment. Rather, the US Department of Labour, an independent organisation (and a branch of government rather than a freestanding entity) computes both measures.
This is the principle of division of responsibility and measurement or judgement. You cut, I choose.
Google are both measuring, and rewarding, website performance, as well as designing and distributing the principle tools that benefit by both choices. That's an extreme locus of power. And, history shows, generally a Bad Idea which Ends Poorly.
Also given their market share as a search engine, they also get to decide which websites you will be able to "discover" additionally incorporating their performance metrics into their website ranking. So not only a website will get a "slow badge" but will also be downranked into oblivion.
The issue is not with the browsers, it's with the damn stupid sites out there. 3G is pretty much useless out there, let alone 2G.
Yeah, it's been years and years since I did much browsing with an ad blocker off.
https://developers.google.com/speed/pagespeed/insights/?url=...
Gmail scores a 50% on Google's own PageSpeed. And that's just the login screen. If Google can't even meet their own metrics and standards then they have no place telling other people what they should be doing with their websites.
The fact that they are failing their own if anything, shows that the tests don't discriminate. It's defeatist to say that we shouldn't strive for faster websites if some webpage fails. I really like how dumb f*s making 40MiB pages are now finally punished.
That is to say, I don't think e.g. Trello would really care if their site was "slow to load" either.
You might want to take a look at Brave, which uses Chromium underneath, has Tor built-in, is compatible with Chrome’s plugins and even has a business model based on paying people to view ads only if they opt-in: https://brave.com/features/
Or is this just a way for Google to kill off the progress bar, too?
If this gets site owners to work more on loading speed so they can get a badge that's great. I used to work on mod_pagespeed and one of the big problems was that publishers just didn't care that much about loading speed.
(Disclosure: I work for Google)
Can I expect Google to do the same about data that may be sent by Chrome to Google without users realizing, just so users can make informed decisions?
> Both Android and Chrome send data to Google even in the absence of any user interaction. Our experiments show that a dormant, stationary Android phone (with Chrome active in the background) communicated location information to Google 340 times during a 24-hour period, or at an average of 14 data communications per hour. In fact, location information constituted 35% of all the data samples sent to Google.[0]
[0] https://digitalcontentnext.org/wp-content/uploads/2018/08/DC...
The only trouble is you'd have to find some way to keep developers from using the DOM as extra memory. But the capabilities of Web scripting languages, outside perhaps some very strict and explicitly enabled on a case-by-case basis sandbox, really ought to be limited more anyway.
I think the principle is a fine one (though it is a bit odd considering the web's main source of slowness is ads/tracking tech, and... that's Google's main business). But in practice I'd bet that - like most of Google's broad-strokes efforts - there will be many edge cases/outliers where people get penalized unjustly, and there won't be an appeals process.
"Better" as prescribed by who? At this point, I'm under the impression that if you're not implementing AMP for content, Google is going to rank you lower and now publicly shame you to users. They _say_ this is not the case, but it's impossible to ignore now that they're introducing naming and shaming. It just seems like features way outside the scope of what a web browser should be providing to users.
Editing to add my other thought:
I've built websites that routinely score horribly on Google's proprietary PageSpeed Insights despite fixing everything within my power (usually Google's own analytics scripts score badly), but also score very high on every other reasonable industry test of similar nature. It's hard to convince me that they alone should be an arbiter for this type of feedback given to users.
The previous version of PageSpeed Insights was open source (https://github.com/pagespeed/page-speed) and the current version is a wrapper around Lighthouse which is also open source (https://github.com/GoogleChrome/lighthouse).
(Disclosure: I work for Google)
https://imgur.com/a/RM8JkbI
That question is kind of coming in at the wrong angle. Google has identified the speed at which web sites load as a problem, and have determined that is a problem worth their while to try and solve.
The problem is that it's all the tracking and advertising that's the cause of the slow loading and Google, being as that tracking and advertising pays their bills, can't solve that as the fundamental problem, so they're doing a very odd looking Twister-Limbo set of actions in trying to reframe what the problem is: speed of page loading.
Google are attempting to treat the symptoms, because they profit from the cause.
Google needs to solve the speed symptom before someone else solves the ad and tracking cause (ad blockers, PiHole, etc.) in a more fundamentally non-technical-user accessible way.
Advertising is a contributor, but it's far from being the cause. AFAICT there are five causes, namely slow DNS lookups due to inappropriately low TTLs, a lack of caching both serverside and clientside, page bloat, an overdose of javascript and an overdose of tracking/advertising (which contributes to bloat and javascript).
Making a Rails site pleasantly fast was more work than it should've been. Rails didn't make it easy to cache page components, didn't make it easy to cache the entire page either, made it easy to inadvertently wait on the database. And here's the key, this doesn't seem to be regarded as a big problem. The rails developers and users don't regard slow speed as a big problem. Is that unusual? Do Django, Magnolia, Magento have a different culture? I haven't noticed (but I might not). Assuming not, the root cause is an inattention to making sites pleasantly fast, and that inattention has simply allowed advertising to have the same problem as the rest of the site's software.
Amp is like ten times as slow for me.. Firefox on android, a bug in amp makes the pages not scrollable. Have to press the tiny little icon in the top right, then again press the url, and then wait for the page to load an additional time.
However, do you think more could be done to make the default MySQL/PHP type configurations faster out of the box? If it is possible to speed up the default config of most websites on the internet, perhaps there is an easy win to be had.
I'm pretty sure that most slow websites aren't slow because their server-side rendering takes a long time. This seems to be mostly a front-end oriented thing (especially directed at pages that load MBs of JS); basically if the page doesn't adhere to all the front-end optimisation guidelines.
The real deciding factor is the amount of dependencies that have to be loaded. This includes JS, but usually the JS for ads/tracking is far larger than the JS for the actual UI, even on fully client-side-rendered sites.
What’s slow are the frameworks on top of them, and a lot of that is going to require big changes since things like the WordPress plugin world or most of the JavaScript world have not had a great culture about monitoring and optimizing things. Simply moving this into the category of problems you can’t ignore would be positive - along with tracking data usage for mobile users on metered plans.
Loading...
Usually loads slow.
This also seems to still be in the experimentation phase and is not released as far as I can tell and may never actually make it into Chromium based on:
> In the future, Chrome may identify sites that typically load fast or slow for users with clear badging. This may take a number of forms and we plan to experiment with different options, to determine which provides the most value to our users.
Regardless, I agree. This probably should've been caught early.
I've never seen it load so fast I couldn't click the link. Including on Google Fiber.
Then you can set that to your default view. Ta-da, gmail that's as fast as HN or Craigslist or whatever.
Sure, it won't alert you when new emails come in, but normal Gmail eats so much memory I hate to leave it open, anyway.
Am I misunderstanding what Google is trying to do? I'm not seeing the use case.
However, it might be nice if it makes some sort of objective measure.
They're trying to normalize Google's approval process on users so that they can leverage this feature for a profit.
You don’t want your customers to see that badge while looking for your Product X 3000 Max.
Now, if you just dumped your other ad networks and ran everything through us, I bet it would be load much faster and that badge might magically disappear..."
My experience with everything google has touched lately suggest that this wouldn't improve speed any. Gmail and youtube make continental drift look speedy and even the search page takes 1.4MB and takes over a second to load for me (maybe corporate network issue), that's approaching the size of doom to display a dozen links.
Google doesn't have any moral authority when it comes to bloat.
Edit - for reference HN takes about the same time to load, but that has to cross the pacific ocean whereas google supposedly has local data centers.
That said, if your search page takes over a second, you're right, it might be an issue with your network.
(Note that the table gets cut off on narrow mobile screens... I’ll file a bug)
FCP is 20% of the score. The other metrics capture different milestones in the loading experience. For example Total Blocking Time is intended to bring awareness to sites that may look complete but can’t respond to user input (because the main thread is busy running JS).
The metrics overview that we just launched provides more detail about how our metrics were designed to capture the end-to-end loading experience (or at least that’s what we’re working towards): https://web.dev/user-centric-performance-metrics/
So in the case of your site-that-just-loads-a-spinner example, yes it might have a good FCP time, but it’s LCP time probably wouldn’t be that good, and therefore the overall Performance score would be mediocre.
Long story short, I don’t think it’s as easy to game a good Performance score as you might think
Disclosure: I work on web.dev
HN is behind Cloudflare, and so also has local DCs
We mention that ad scripts are a common type of problematic 3rd-party resource but we use the phrase “3rd-party resource” because there are lots of other common problematic scripts, like A/B tests, social media widgets, and analytics scripts.
Disclosure: I work on web.dev
This sort of basic advice (use browser features to defer loading, and plead with the masters not to ask for so much JavaScript) is obviously already considered by the HN audience and so this link is basically useless.
I sincerely doubt 100% of the HN audience always considers those things.
You might think some of those things are basic, but that doesn't make them useless.
This kind of lack of empathy for new learners can make it incredibly difficult to teach concepts to those who don't have as much knowledge as you may have.
See https://www.youtube.com/watch?v=OkmNXy7er84 for a great video by 3blue1brown on this topic.
Exactly what does "high-quality experiences" mean? Penalize sites with bad colors? Sites that are artsy and an algorithm can't understand? Sites that have been repositories of information for longer than Google has been around? Sites that don't meet Google's worldview? That disagree with Google's politics?
It's becoming increasingly common to have all sorts of pop-ups blocking a big part of the screen at best or adding an overlay across the entire body.
If only I knew that my click would result in that kind of monstrosity I wouldn't have clicked in the first place. So maybe it would be more useful to show an of how many things we need to close before we get to the content. I think that something like this would also help get us to "a faster web".
That seems to cover such things.
Yeah they track you and such, not denying that or supporting that, but Google generally pushes back against the sort of bad experience you find at so many sites.
But so far, nothing's been done yet. This is kinda weird to me because one of the reasons why Firefox came to power (and took over a bit chunk of IE's market) was that it had a pop-up blocker. I don't understand why they aren't doing more to block inline pop-ups now.
Presumably a site that is using the dark patterns you've described would have a low SES. Although if you're interacting with the site in order to get past the ads I wonder if that would distort your SES? Then again, if the site is doing annoying things, I'd probably bail quickly, so maybe SES can work after all...
Disclosure: I work on Google Web DevRel. I don't know if there's any plans to incorporate SES into this badging initiative. I was just reminded of SES last night because Periodic Background Sync API uses it [1] and it seems relevant to this problem.
[1] https://web.dev/periodic-background-sync/#getting-this-right
Pity about that for Chrome, hey.
Another part of me worries that this will lead to a cobra effect[1], where people optimize a page's first load so Chrome says the page is fast, while withholding the main content of the page for a delayed load, leading to even more site bloat. Identifying when a page has actually loaded will be tricky.
[1] https://en.wikipedia.org/wiki/Cobra_effect
Also: it's not a "police state" approach. Google loves a good police state.
Before you downvote my comment explain why the above scenario is not plausible.
This situation differs from eg. YouTube because they do not themselves host the content, and are not subject to copyright laws related to it.
Also: Google is made of human beings who have already protested against, for example, censoring Google within China.
But all the stuff that makes the Web slow and pointless to use is how Alphabet makes money.
So as long as you drink the Google-Aid, you're doomed to a slow web of garbage.
Pre-ajax online maps? Almost unusable. I certainly wouldn't want to return to those days.
Use an email and newsreader for email. Use a full mapping suite to download specialized map data. Don't force a web browser to shim into those niche jobs.
Old adage I learned with computers: Do One Thing, Well. That's what each program should be. One thing.
Yeah, pretty much. If web sites would stop stuffing these giant js frameworks pages + 3 trackers + 3 ad networks into all page we could be using like iPhone 4 now.
This looks to me like a positive effort. I'm not thrilled with overlays like this, and I'm not thrilled with baking this kind of stuff into the browser. It feels over-engineered and weird.
But, I think it's a better direction than AMP.
There are a lot of ways this could go bad, but very cautious thumbs up from me.
FE devs want to be taken seriously, but they refuse to learn the lessons the rest of us have already learned.
If FE devs would get their crap together we wouldn’t see posts about Google trying to wrest as much control as possible away from them.
The business can't easily and explicitly monetize "fast" to the same degree it can bloated features and ads/tracking.