Nothing says “we’re listening to your concerns about AMP” like rolling it out further to interfere with a function that is even less suited for AMP.
Also, technology companies have a real problem assigning appropriate value to maintenance tasks that just keep things stable and usable. I’ve had infrastructure responsibilities over the years and the hardest thing about it was that nobody really knows or cares how much trouble you put into having things work flawlessly for months or years on end. It was important to find lots of visible tasks to go along with the invisible ones. I guess you end up with things like 40 Google chat clients and “hey let’s screw with E-mail” when there isn’t enough promotion-worthy work left to do in those areas.
Part of why I don't advocate for CDNs when you don't need them is because I want to build robust sites that work for years untouched. For timespans over a year, anything not on your server is brittle. Oops, CDN changed its URL/didn't update their ssl ciphers/went bust and shut down completely and now {js-framework}/{css-library} is missing and my site is broken. What an unforeseeable circumstance!
That's why I like to map one of my own subdomains to the cdn service.
So everything is at cdn.example.com and if I change providers, it's just a dns record change and everything is ready, even if I want to just host my own content.
Doesn't that kill the possibility that a visitor will already have common content cached when visiting your site for the first time? I know that's not the only reason to use a CDN, but it's a pretty big one.
In my experience, the variety of specific versions of libraries sites are locked to dilutes that performance benefit. Just look at a cross-sampling of sites calling jQuery or <insert your favorite library or framework here>.
In theory, the maximum benefit of a CDN only comes if everyone is on 1) the same version or, similar but different, 2) an evergreen version. And the latter is a big red neon sign screaming "DANGER".
Honestly with all the versions of js libraries and all the CDN hosts, the limitations of cache size and the insane bloat of webpages, I think you're going to have to be pretty lucky to get any beneficial cache hits from unrelated third party sites.
IF you have some stuff you think some visitors will have cached, well then you can use the standard google or jquery CDN or whatever (they're free anyway). For everything else you would run from your own CDN url.
I thought that too but even for the most common stuff like font awesome cdn cannot be trusted - just too many silent outages that were only discovered from user complaining because they impacted different geographical areas differently..
IIRC the argument was that JS bloat is okay "because we can cache common content through CDNs" ... or that's how it felt at the time :)
It sort of/kind of started with jQuery, and in those days including jQuery was considered somewhat bloaty. I think it was about 18kB minified back then? Today their site says it's 30kB.
Either way that's miniscule compared to having a few pictures on your webpage. Having much more JS than that, honestly seems like true bloat to me, which I don't think CDNs should facilitate anyway (so much untrusted unknown unchecked code doing very, very filthy things).
My point is, it wasn't a very good argument back then either, but it became normal because people did it for other reasons, too.
The main reason people did it, was that it was just so much easier. Just copypaste those 1.5 lines of code in your <HEAD> section to include the latest version of jQuery from Google's CDN, instead of downloading it and putting it somewhere in your source tree and now you've got to keep track that different parts of your codebase written months apart don't accidentally use slightly different versions (because it's ugly, not because it mattered a lot otherwise), etc.
Such convenience!
And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code, then the web is basically fucked anyway, and we got much bigger problems. Which seemed like a reasonable threat model / security trade off at the time.
And now we're here.
About a week ago Google got caught hosting hostile ads that included cryptocoin miners inefficiently wasting users' electricity for a few bucks (profit insignificant compared to the cost of energy wasted). And apparently Google's offering to blindly host 3rd party JS to all users on the entire Internet everywhere (except the adblockerati), via their fucking ad network, has been expected behaviour for over a year at least and nobody gave a peep when that malfeature appeared.
I still don't know the exact date when or if there even was an announcement when they allowed advertisers "sure do whatever you like to their browsers, run some code, compute stuff, track them in all the ways we haven't dared to deploy publicly, or yet thought of, have at it, you need this, you do you".
So yeah, the web is fucked, we got bigger problems and hell no you can't trust Google any more.
> Either way that's miniscule compared to having a few pictures on your webpage.
A visitor can decide to not display images to improve performance and this will not break the website, blocking the (often not useful) js on the other hand...
> And if someone asked if it was really a good idea to blindly load 3rd party code and run it in the context of your own domain? Even I told people this sometimes: Well if you can't trust Google serving you secure code,
You overlooked the privacy and personal data issue here. It's a bad idea to rely on anything google because it means that you give away the privacy of your visitor to one of the worst offender no less.
> About a week ago Google got caught hosting hostile ads ...
Google has been delivering malware, spyware and that kind of things for years. It was even considered a major vector of infection (usually someone looked for flash on google and clicked on the first results which happened to be a google ad for an infected flash installer)
Many providers simply map to your live site structure. So I keep everything on my own site and do the initial upload there. The CDN looks to my site to get the original copy when they receive a request for a file they don't have cached.
Why would it fail today? If I can't serve an asset then my whole server is down.
If you are an e-commerce site serving hundreds of images worldwide then CDNs make a tonne of sense.
If you just have a simple site or SaaS getting decent traffic, why add a failure point by including your choosen JS with a CDN. No one batts an eyelid when you add ten images to the homepage but somehow a single, much smaller JS file is too much extra load. It doesn't stand up to reason.
And it will supplant Duo and Allo, that were/are supposed to supplant (or augment, or co-exist -- can't we all just get along?) Hangouts, that was supposed to integrate SMS and MMS, but bollocks.
Anyway, I prefer my email to remain immutable after initial transmission. I don't need another Snapbookthingie...
Which reminds me, Google: You already hosed search results with your first... or second, or third, buzzzzzz... big social, dynamic (comments) push, Plus.
And almost nobody liked Buzz, nor the way you tried to shove it down our throats.
Are you really going to take another stab at sabotaging one of your successful products -- this time, Gmail?
You HAD a successful social platform: Reader. And you nuked it.
You want "social" and "changing content"? Bring back Reader.
I was really upset by it too. I used to start my day with Google Reader the same way my dad used to start his day reading the newspaper. This was a crucial part of my morning ritual, and I trusted and relied on Google to maintain it for me. The sudden announcement that it would be taken away felt like a betrayal. It shattered my image of Google and made me completely rethink my dependence on them and seek out alternatives wherever I could.
I was too. For personal use I eschew new products by Google. iPhone is starting to have big issues but I'll never go back to a Google phone, computer, tablet etc.
AMP has gotten me to finally switch to Duck Duck Go. Gmail is too difficult to leave, but AMP for gmail may finally get me over the edge.
Still wish there was an rss reader as good as G. Reader.
It was probably the single best social thing I’ve ever used. It was unique as it was actually social. Both my teams at work and family/friends used it as a way to comment on news and share stuff of interest. It was also a product of an earlier era where there was excitement over anything Google released.
Google+ tried to capture many of the good parts of reader... but it was too forced.
The social aspect was the one part of Reader I never got. I don't think anyone I know uses RSS feeds outside of podcast subscriptions. I just liked that it was the only RSS reader I had ever found that just worked, and it synced my state as a bonus.
AFAIK, Google Now, which is well baked into Android uses RSS feeds. It might not be that people subscribe to them manually, but I'm sure there are plenty of people who do consume content from RSS feeds through things like Google Now. I personally find it nifty to receive updates on blogs according to my search history.
Also, technology companies have a real problem assigning appropriate value to maintenance tasks that just keep things stable and usable. I’ve had infrastructure responsibilities over the years and the hardest thing about it was that nobody really knows or cares how much trouble you put into having things work flawlessly for months or years on end. It was important to find lots of visible tasks to go along with the invisible ones. I guess you end up with things like 40 Google chat clients and “hey let’s screw with E-mail” when there isn’t enough promotion-worthy work left to do in those areas.