Hacker News Reader

Comment by magicalist | Hacker News Reader

> Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index.

But who will measure it "objectively" (leaving aside no one agrees on how to universally measure load speed).

Googlebot? From what location and what machine types and how often? Should I get search results based on an average of all possible variables or the closest matching my locale and device? What happens when page content changes? What happens when the page sometimes loads slow content (e.g. ads) and sometimes doesn't? What happens when SEOers start cloaking their ad loads or taking advantage of flaws in the benchmark?

It's good to have a speed signal in search rankings, but this petition shouldn't pretend that's an objective replacement for something that always displays content first and loads media and third party content async

View on HN

> But who will measure it "objectively"

One potential solution that fits the theme of the letter could be logic like this:

    MAX = <reasonably fast load time>

    if page loads in > MAX:
        -> punish page rank

Rather than the current logic:

    if page uses GOOG proprietary:
        -> show at the very top
        -> trick anyone that clicks
        -> profit
    else:
        -> ban website
        -> reach out to sell AdWords

"Reasonably fast" could be relative to the context - for example, ecommerce results might be a bit larger on average than news results, etc., so not a static "3 seconds at 3G speed".

"Reasonably fast" could also be defined more loosely as "page uses good optimization practices" (e.g., like a YSlow grade).

Google already measures a bunch of site speed parameters (time to render start, time to render the content text the user is trying to read/search for, etc.)

They factor in all that stuff to a user happyness metric which impacts rankings, probably via a bunch of machine learned models.

The AMP logos and stuff are to try and force webmasters to take speed seriously. For years people have said it's important, yet big sites like eBay and Amazon, who certainly have the financial means and motivation to, still take 10x longer to load than what would maximize both revenue and user happyness.

> They factor in all that stuff to a user happyness metric which impacts rankings

And speed is way down on the list. Try searching for lyrics to any popular song and tell me it isn't so.

All they really need to do is add more weight to it. But they don't want to because that breaks the lock-in that they are striving for.

  >  MAX = <reasonably fast load time>

If you define 'reasonably fast' as ~10ms after click, the only possible option is AMP. Even a .txt file will be orders of magnitude slower.

Privacy reasons mean that it is basically impossible to load the content from the publisher's server until after the user clicks on the result. If you wait until the user click event to load the content, then there is nothing you can do to avoid a full network round trip.

AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load.

There are unavoidable technical requirements to do this:

- Loading from Google's (or link provider X's) servers to preserve privacy.

- Constraining the html so that the load itself can't break privacy or add jank to the search result page.

If you aren't willing to accept these constraints, then you are always going to face a network round-trip in added latency. You can't have all 3 of:

- Zero perceived latency

- Privacy

- Serving from the publisher server

You can only pick 2. AMP forces choosing the first 2 which are what the vast majority of users care about.

Then AMP goes way out of it's way to give publishers back everything they could possibly miss from the 3rd.

> AMP preloads the minimal content before the click, removing the round-trip. That's the whole magic, and the only way to get the 'instant' load.

There is another way which enables almost instant loads. Turn off js completely. Try it yourself before you disregard it. It literally turns page loads instant over a regular home connection.

This is strictly slower than an AMP preload, which is why I mention that even a .txt file will load slower. The .txt file document still requires a network round-trip, regardless of javascript.

On some wired connections, a network round trip is within user-perceivable 'instant', but for many people on mobile devices, this is very noticeable.

https://hpbn.co/mobile-networks/

Even on the best LTE networks, the 'core network latency' is 40-50ms. 'core network latency' is the latency for getting the packet from the phone to tower to the packet gateway. This is before the packet even goes on the internet. And you need to double it for the round trip. You usually need to double the whole thing for initial DNS lookup.

Best possible latencies for an html page load on excellent LTE connections without prefetching are around 150-200ms. Most users in the world will experience >1s. A United States major city wired connection is not at all representative of what most people experience on a mobile connection.

Yeah I was talking about computers, not phones.

Then you are missing the point of AMP.

Increasingly, phones are the dominant computing tool accessing Google search results. Optimizing for phone experience is key to serving the largest growing demographic of searchers.

Preloading website content is not what I want for my phone. I have a very low datacap and I go out of my way to disable AMP and preloading because web publishers believe that my bandwidth can be used freely by them in an effort to "reduce latency". Instead it robs me of the little data I have for my cap.

That's fair, but I think losing perspective of the tradeoffs. The AMP preload will fetch only the main html file and AMP javascript. Images, videos, etc are all deferred until later. The javascript is cached for a year, so you probably already have it. So, compressed, this is probably ~100kb or less.

Google doesn't start preloading 50 documents, it loads the top result or 2. Even viewing a hundred amp pages in a month is going to cost you less data than one 10kx10k unoptimized image that a publisher decides to load, which happens a lot. Note that AMP optimizes images too taking into account your device resolution, so it's most likely saving you bytes.

I don't want anyone preloading anything on my mobile connection other than the absolute necessary. Period.

Everything else wastes my bandwidth and I don't care that it is only 100kb, my monthly, effective datacap is about 50MB and I always browser without images.

The "100kb or less" is only about 500 pages preloaded, not accounting for the size of the google webpage itself. I'd rather not have any preload at all.

Note also that Google doesn't show AMP for desktop user-agents.

Any WebPageTest comparison between Desktop and Mobile will demonstrate that RTT can be _vastly_ different between Desktop and Mobile.

Just look at Time to First Byte (TTFB); when you pile on SSL negotiation (since most have moved to HTTPS), the advantage is even greater since all AMP pages currently fall under the aegis of Google's domain and all non-AMP pages will require that overhead at first click.

> - Constraining the html so that the load itself can't break privacy or add jank to the search result page.

Why this? If the HTML is already loaded from Google's servers, the load shouldn't be able to break privacy even more, and jank shouldn't be affected by the specific HTML that's being served, just by its size. So Google could just preload everything that's small enough.

Good question. Preload that actually renders the documents includes running enough javascript and parsing enough CSS that the initial document will render. With a non-constrained document, that can include fetching resources not on Google's servers and which can peg the CPU, causing jank.

If you do constrain what can run in your preload to avoid these, you end up designing AMP.

Google owns a browser. They should be able to measure average load times for every page on this planet from almost any location

(Of course User permission must be granted, but shouldn’t that be feasible?)

I wouldn't be surprised if they already have an opt-out feature which does just that.

They do..for over a million websites! https://developers.google.com/web/updates/2017/12/crux

This data is a much better indicator of how fast a page is vs if it is AMP or not.

The one thing AMP does right is have a hard and fast set of rules that pages must follow. Page performance for regular web sites dies a death from a thousand cuts. Was is the web developer who added that last analytics tag that made it slow? Or was it the 12 other third-party tags that already existed? Unless you have a single self-contained team who control the entire stack, do a ground up rewrite, or have a dedicated performance team, it's hard to hold the line against a thousand little things that slow the web down.

People are already cheating with AMP by putting only introduction on the AMP page and then linking to the heavy main content at the end. Cheating is something that Google has to deal with all the time.

Starting February 1st they'll be blocking AMP doorway pages.

https://webmasters.googleblog.com/2017/11/engaging-users-thr...

So making my own page display what I want is cheating now?

No, serving differing content based on the source, making users double click to view it all, while trying to reap the “SEO” benefits of AMP is.

GoogleBot runs only in a few datacenters in certain locations in the world with amazing connectivity.

It is a horrible predictor of load times.

Chrome's own dev tools can emulate slow connections for you. If their browser can do that, why not their crawler?

Because the user isn't sitting at a datacenter.

An user in Indonesia isn't at the closest datacenter in Singapore. It doesn't matter what you do, you can't, from Singapore, try to emulate what an user on a particular ISP in a particular city in Indonesia will face.

In case it isn't clear:

Consider 2 websites, both have hosting in Singapore, but one also uses a CDN in Jakarta.

The Google crawler running on the Singapore datacenter connects to both websites, speeds are great because they are sitting just next to the datacenter. Both get great ratings.

An user is in Jakarta, and tries to connect to both websites. One of them takes a century to load, because it has to load everything from Singapore, and international cables from Singapore to Jakarta are expensive, so connections are capped. Experience sucks.

The second website uses a CDN in Jakarta, located at the local coloc facility to which the user's ISP is also connected to. The website loads instantly.

CDNs today are located in every single small ISP, in all countries, in all medium-sized cities in the world.

The poster was arguing that negative network conditions can be simulated.

If the problem is a lack of information about global network conditions, then you can deploy canary machines around the world to gather that information.

They can be simulated, but not predicted.

> If the problem is a lack of information about global network conditions, then you can deploy canary machines around the world to gather that information.

You'd need to put machines in every single city and every single ISP in the world continuously testing every website in the world.

Doesn't make any sense at all. That's not how networks work.

It's unfeasible, but also completely unnecessary. CDNs can give you some speedup, but they don't magically make a site smaller and less resource-intensive to use.

OP was talking about a "neutral" speed index. You're talking about solving for every possible combination of user, ISP, and website. There's probably a reasonable middle ground in there somewhere.

But that's the point, it doesn't depend on a "neutral" speed index, it varies from website to website, ISP to ISP.

If you're in Jakarta trying to access a certain website, if that website is available at the local CDN might make a bigger difference than which ISP or even which plan you're using.

You could have a 1Gbps fiber connection from your ISP in Jakarta. If you're trying to access a website in Singapore the your ISP's international link is congested, that 1Gbps will be useless.

OTOH, if you have a 10Mbps connection, and you're trying to access a website replicated at an Akamai CDN in your ISP's network, it will be way faster.

If we accept your argument that Google can't measure the speed of a webpage then wouldn't it also follow that Google can't know if the AMP version of a page is actually faster than the non-AMP version?

> If we accept your argument that Google can't measure the speed of a webpage

Correction: Google can't predict the speed of a random webpage to a random user around the world.

But you can reasonably predict that pages hosted at widely available CDNs around the world will load faster on average than pages not available.

Google _can_ predict the speed of any webpage to any user. Google Analytics data is enough. Your whole thread is predicated on Google having that one product (crawler). They have everything.

If a site is running Google Analytics, couldn't that information feed back into page loading speeds?

You basically have the same problem then, of forcing sites to use google products in order to be ranked highly.

Beyond the fact that the network can be mapped (Google surely does this) and simulated, I feel the more important observation is that this doesn't matter. A good estimate of bloatiness should not require knowledge of network topology.

CDNs are a hack that can make websites load a bit faster, but that's about it. It won't make them use less RAM, or consume less of your data cap. Ultimately, performance is about the size of the site, the resources it uses on the client, and the number of requests it makes. All of which is independent of the number and location of CDNs.

> A good estimate of bloatiness should not require knowledge of network topology.

It does, because the definition of bloatness depends on the network speed.

What counts as bloat for an user sitting in Singapore isn't the same as an user sitting in Jakarta.

> Beyond the fact that the network can be mapped (Google surely does this) and simulated

Network topology is irrelevant in this case. The ISP in Jakarta might have a satellite connection to Singapore, but have a CDN and it will load faster than in another ISP with a 10G international fiber link to Singapore.

> All of which is independent of the number and location of CDNs.

That's completely wrong. Today, the vast majority of internet traffic is served from CDNs, CDNs (and their placements) are critical for the internet as we know it.

> It does, because the definition of bloatness depends on the network speed.

No, it doesn't. It depends on the proportion of actual content to the unnecessary cruft. The difference is that what a Singaporean considers bloat might prevent someone in Jakarta from accessing the site at all.

> That's completely wrong. Today, the vast majority of internet traffic is served from CDNs, CDNs (and their placements) are critical for the internet as we know it.

That is if you include streaming video, which is off-topic for this discussion.

Imagine a perfect world with the ultimate CDN solution - something like IPFS, which ensures everyone is a CDN to everyone else (instead of wasting bandwidth with multiple downloads of the same content). The concept of bloat wouldn't disappear in such a world, because bloated websites will still require you to download unnecessary amount of data to your machine, and will reduce your computer's ability to multiprocess while also using up your battery life.

I stand by what I said before - CDNs are a hack (basically a hand-rolled, rudimentary distributed system) to give you some extra download speed. They don't solve the problems of download size and resource usage.

The argument about bloatiness reads like a privileged position, IMO. Everyone is interested in getting customers with shitty 2G connections and tiny data caps, because there literally billions of these people and nobody wants to bet that they're never going to have money to spend on your services.

If you pretend that all your users have net connections like the US, Europe, or parts of east Asia then you're going to end up as a small player in a balkanized internet. That's why all these companies are making aggressive investments and acquisitions in other parts of the world.

CDNs are also part of the fundamental reality of the internet. Could you imagine Netflix or YouTube without CDNs? The amount of network capacity investment necessary to run the internet as we know it without CDNs would cripple it.

And it's not just the internet, but it's a fundamental fact of computing that you have hierarchical caching layers with some data far away and some data closer.

No CDN is changing the fact that your website with 2MB worth of content and form weights 20MB and loads another 10MB of trackers.

It's not about privilege or capturing emerging market. It's about laziness and waste, pure and simple. The same bloat that prevents someone from accessing your site on a smartphone in the middle of Africa is also significantly slowing down the computer of someone in western Europe, and eats into battery life too.

And let's not bring streaming video into this as it's completely off-topic.

I've heard this argument before. Think about the people with shitty 2G connections and equally bad backhaul or backbone networks. The fact is these people are not necessarily as interested in your 2MB pages as you'd like. They have their own web pages and apps that they use. They do care about CDNs because some of these networks are just plain bad, and it's not the first hop.

And that's the privileged position. Bloatiness is annoying if you're an American reading American pages, or a Spaniard reading Spanish pages, and we like to complain about it because it means the difference between being able to read an article on the subway and having to wait for the next stop. But I'm never in a position where I have to complain about the backhaul network or the backbone.

In the future, please don't try to police "off-topic" conversation.

The original point I made -- that Chrome's dev tools can simulate a slow network connection -- got nit-picked by people saying it can't figure out which CDN serves which ad bundle. This is not a useful, relevant or even coherent reply.

Public web sites that only work for "first world internet" customers shouldn't be a thing. Sites that load 100MB of ads and trackers and fifty different JS frameworks to display a few paragraphs of text should be getting the search-engine death penalty until they clean up their act. They should be thinking about people who aren't on fast broadband connections. If they aren't, the search engines should be.

YouTube learned this from the "paradoxical" result of a lighter-weight page increasing load times:

http://blog.chriszacharias.com/page-weight-matters

(spoiler: it was because the lighter-weight page meant it was suddenly usable by people who had slow connections who couldn't use it previously, and those people began to use it, which skewed the average load time higher)

> The original point I made -- that Chrome's dev tools can simulate a slow network connection -- got nit-picked by people saying it can't figure out which CDN serves which ad bundle. This is not a useful, relevant or even coherent reply.

Let's say your website is hosted in Jakarta, and serves Indonesian customers. You make it lightweight and fast.

Your competitor hosts its website from Singapore, and is much heavier.

Now Google, from its datacenter in Singapore, wants to test the load times for your website and your competitor's. Sadly, the host you chose doesn't pay for a lot of international traffic on the cable to Singapore, since it primarily serves the Indonesian market. Google tests both sites, and your competitor's, based in Singapore about a mile away from the Google datacenter, loads several times faster, besides being heavier.

Google ranks your competitor higher, and you are pissed off, as your customers load your site faster.

Now another case: you and your competitor host your sites in Singapore. You build a lightweight site, and your competitor's is full of heavy assets, with oversized images, etc. Google tests both of your websites and yours loads faster, and is ranked higher. You're happy.

But your competitor signs up for Akamai and replicates the heavy assets in local servers in all the major ISPs in Indonesia.

Customers in Indonesia search and see both your and your competitor's results. You rank higher and get more clicks, but as your traffic is subject to the congestion on the international cables, your site actually loads far slower than your lower-ranked and heavier competitor. Customers are unhappy.

In all of this, simulating a slow connection on Chrome's dev tools is irrelevant, because you don't know where the bottleneck is!

Again you are missing the point. And at this point it's hard not to believe you're missing the point deliberately.

None of this is relevant, though.

Simply simulating a globally slowed-down connection will tell you what's going to be a problem. And, really, common sense will tell you what's going to be a problem, too -- if a site "needs" to load 100MB of ads and trackers and other JavaScript to display a couple kilobytes of actual text content, then you have a problem. A user on a slower connection is going to see that site take forever to load even if there's a CDN across the street.

This is probably the easiest problem to solve. Hosting a GoogleSpeedTestBot in every city with the sole purpose of speed testing a page would have laughably negligible impact on Google's resources.

You're proposing hosting thousands and thousands of servers across every city in the world where each server would be accessing all the top 1M sites in the world every day and measuring the speed of each page in that site?

Seriously?

Not every day; at the time of publishing, and maybe few days later. (This could be improved even further: you don't need to access every article. If you could identify a page that's representative of a real article, that could suffice. Maybe have periodic random checks to see if this is still representative.)

Not every city; the top 500 cities would probably cover 90+% of the users.

You're not understanding the scale of Google. They're incredibly good at exactly this stuff.

Oh, I am, but maybe you're not understanding the scale of the internet. Connections, cables, CDNs change on a daily and weekly basis.

Is a cable is cut between Jakarta and Singapore, it can take months to fix as Indonesia only allows Indonesian-flagged cable layers to operate in its waters.

Individual datacenters, CDNs, cables are going offline constantly, so you'd need to be continuously testing every site to rank it correctly. Not only that, each page in a site might have a very different structure, so you can't just rank a site, you need to rank individual pages and articles too, which means testing every new page and article from every city.

I guess you're not getting the scale of that...

AMP standardizes the CDN serving part, largely eliminating that issue. AMP articles can't prevent 3rd party CDNs from caching them, which means that they can be served from the closest CDN after the first time they are used.

Or just use your established botnet aka chrome and android.

Counterpoint: You can already simulate the way bad Internet connections work. You don't want that introducing noise on top of the site's metrics. Measure the site itself, then apply a variety of scenarios for what practical fetches look like.

If you have the number of roundtrips and size of documents you can easily calculate page load speed dependent on latency, packet loss rate and connection speed. That allows you to simulate nearly any connection in the world.

Which is the reason why Google focuses so much on the number of roundtrips. For most, downloading 50kbyte doesn't cause a lag but 10 roundtrips before the site can be rendered do.

Measuring page speed accurately seems like a way smaller engineering problem than attempting to convert the whole internet to AMP.

Here's a potential solution for Google: just log load times for people who use Chrome and are logged in to their Google account at the browser level.

All the hard work of eliminating abuse is something they've done already for those accounts. And their userbase is so big, and presence so strong, that it would generate pressure everyone would benefit from.

Erg, the idea of Google phoning home information about each page I visit at the browser level is a bit terrifying...

How confident are you that that doesn't happen already?

It certainly does happen already if you are opted into it.

It certainly does happen already without having to opt-in for the many sites that collaborate with Google, reporting your interactions with their site to GA.

I was trying to avoid making a controversial statement. I didn't mean to imply that you were explicitly opting in, just that you are opted in.

It does happen already - after all, you have shared browsing history between logged in devices using Chrome.

My idea doesn't require anything new except them measuring load times, which I'm guessing they're doing already for improving Chrome, and then using this data to influence search ranking. Everything else is already set up and working, and you opt into it if you're using Chrome and are logged in browser-wide.

It already happens with every site using Google Analytics, which is nearly every site you visit...

Unless you are running add-ons that block Google Analytics, which I would assume everyone here would already be doing.

Everyone here constitutes maybe 1% of total traffic on the internet; still plenty of data points to be had.

Last I knew, you couldn't disable Chrome's async DNS feature, which will bypass your system's configured DNS servers and use Google's own. So, while certainly not the same level of tracking that Google Analytics or even browser history can perform, many (all?) domains you visit are still sent back to Google in one form or another:

https://bugs.chromium.org/p/chromium/issues/detail?id=432236

Well, I don't use Chrome. Do you know if this affects Firefox as well?

It shouldn't. I must've just gotten myself mixed up. I thought this thread was about Chrome phoning home. Sorry for propagating confusion.

Holy hell. So this is the dumb DNS crap Chrome is doing. I had occasional issues with Chrome suddenly not being able to load anything due to what looked like obvious DNS issues, except they didn't affect anything else and there was no way for me to do anything with it except wait it out. There were moments I thought I'm imagining things.

Yeap! And if you're on a private network you can leak internal domain names. Or, if you some hosts that are available publicly but resolve differently internally, you'll get the wrong IP. I think the only real solution is to kill Google's DNS IPs in your routing table.

UMatrix is a good way to get an easy visual of what's getting sent and loaded and from where.

If if was every page, that would be terrifying. But if it only measured the speed of pages directly linked from a Google search result, I would be fine with that. Google wouldn't be learning anything new there.

> or taking advantage of flaws in the benchmark?

Then you improve your benchmark.

That's a cat an mouse game that search engines and SEO companies have been playing for years. "Improve your benchmark" only works when you don't have adversaries.

Edit: To clarify, "improve your benchmark" is not a viable strategy by itself any more than "put your opponent in checkmate" is a viable strategy. As advice it is unhelpful. You generally have to mitigate flaws in the way you rank pages, keep large parts of the algorithm secret, and attack the economic viability of your adversary's strategies. Rather than going for checkmate, you want your opponent to resign so you can do something else instead.

There have been incentives for bad behavior on the web for so long that I don't think we have any hope of coming up with any kind of automated benchmark to tell us which pages have good user experience.

> "Improve your benchmark" only works when you don't have adversaries.

If this were true, then there would exist no search engines consistently capable of finding content highly relevant to the user's query -- as opposed to just returning promoted content, which according to your premise is always winning the adversarial battle.

Sure, there is an adversarial element, which means there is a constant 'battle' for 'fairness' among results (or whatever your goals are as a search engine). But in reality, search engines as a whole seem to work rather well at finding what we want. Of course results are biased from adversarial pressures (and that's what we're discussing on this thread), but it does seem possible for "benchmarks" to work well in an adversarial environment.

Search engines work by not just improving the benchmark but also making the benchmark a trade secret. That's what I was saying. And if it's a trade secret I would say that the word "benchmark" is a misnomer. Broadly speaking, a benchmark is a standardized way of measuring something, and if only one company can perform the measurement then it's not really a standard.

> If this were true, then there would exist no search engines consistently capable of finding content highly relevant to the user's query -- as opposed to just returning promoted content, which according to your premise is always winning the adversarial battle.

I can’t tell if you agree that google doesn’t return highly relevant content or if you just get better results than I do. Almost all my search results are dominated by low relevance high click through brands, regardless of quality. For example: quora often replaces high quality content with low quality paywalled answers researched from wikpedia or other public resources. 10 years ago you would have gotten metafilter, which is (imho) objectively a higher quality source less hostile to web users.

> I can’t tell if you agree that google doesn’t return highly relevant content or if you just get better results than I do.

The degree to which search engines are gamed successfully by adversaries is not the variable I wish to present a strong opinion of here, which may explain your confusion on my position here.

Instead, I just wanted to illustrate the logical connection between an adversarial-defensive ability to rank based on [website loading speed], and the ability to rank sites based on [any other factors]. If you can pull off adversarial defense of the latter, you probably can achieve the former with even less effort.

That said, I do present to you tentatively the claim that most popular search engines do a decently good job at fulfilling their goals, even if those goals are not in alignment with users' goals in many cases.

For example, there are certainly many examples of paid ads given preferential treatment in search results; however I do not believe this constitutes a case of an adversary beating the search engine's metrics. Rather, it is a consensual relationship/contract between the search engine and an advertiser being fulfilled. Whether this contract/relationship is in the best interest of consumers, is another matter altogether, of course.

Reply on news.ycombinator.com