Hacker News Reader

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.

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.