A new approach to web performance
ampproject.org
ampproject.org
This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.
https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...
I wonder what the average Googler would make of OSI standards like x.400 and x.500.
Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.
That's much worse than Google killing Reader, because reader is just a reader, you can still switch to a different one. If the source doesn't provide an RSS feed, there's not much you can do.
If a single company killing a sigle product could kill RSS, then it wasn't that alive in the first place.
The fact is, after 10 years of RSS being available in blogs, news sites and elsewhere, Reader still had an insignificant number of users in the web scale of things. A few tens of millions (all estimates put it in the low tens, like 20 to 40 millions).
And did you just say "few tens of millions" of users is insignificant? How many users are we here on Hacker News again?
I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it.
RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.
RSS -> Twitter
Usenet -> many proprietary platforms
IRC -> Slack
XMPP never took off
Many open, interoperable services died off or never took off, but companies built similar services and are enjoying success.
/s
Also, it's a lot easier to make good protocol decisions if you don't have to get them published into a standard and deal with the beauracracy etc. If you look at the level of polish in slack vs one of the many previous open source irc clients, the difference is clear. It helps to have money.
Yes.
>How many users are we here on Hacker News again?
I'd say well under a million (or around that at most). What does that have to do with anything? Did anybody say that HN has a significant amount of users web-wise?
Slashdot and then Digg, which were both something like 100 times HN in size fell off the side and nobody much cared.
an order of magnitude more than G+
G+ I have used a bit. I guess I'm not alone.
Just a data point since it seems to be unreasonably many G+ haters around here.
There's nothing on that in the Github Wiki and neither on the project page. The superset of HTML is specced, yes, but information on the containing ecosystem is spare.
Because of dominance posturing and fights between the multiple parties involved in the development of RSS, it is a train wreck of ad-hoccery and incompatibilities, and serves as a prime example of how not to do things. https://web.archive.org/web/2004/http://diveintomark.org/arc...
> Remember who actually killed it?
Atom.
Loading the article in your validator reference shows me 80 some requests returning from 48(!) unique sources.
> The page you are currently reading is an AMP HTML document.
Yet it has a proper doctype of "<!doctype html>"
I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just html and common sense.
They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.
I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.
It may not be so sinister because it's a badly thought out approach indeed. Although they got quite a few big partners already, this undertake requires rewriting the whole Web which is too much to ask even if you are Google.
But please tell us more about the business model, I see you're a Google employee.
Same as before, just with happier users including myself. Happy users are good for business in the long term.
The problem we are solving is that many sites don't.
Forgive the skepticism but this screams XKCD927.
With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.
That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.
A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.
I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change. 't
You also didn't address my first point: If you're building this for people who don't make the effort right now, why would they suddenly make a seemingly bigger effort to support something they haven't even heard of before today?
We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.
To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.
In case you haven't tried, check out this video https://www.youtube.com/watch?v=i2_lAEzmOPo&feature=youtu.be I so much want my experience to be like that (or try g.co/ampdemo on your phone yourself).
Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.
But I like to present both a solution "this is how you make it fast" as well as the penalty.
If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.
Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.
In the world of the web platform it doesn't get much more standard than that.
Which begs the questions: Who prerenders and on what criteria?
Assume page A which has a link to AMP-forked page B.
Does that link need rel=prerender for every browser? Does one need to query the AMP-ness of every page one links to? Does one need to be Googles page cache to link to AMP-pages and get in the benefit of prerendering?
Or is the prerendering implemented in the AMP runtime? Does it only work if page A and page B are both AMP-enhanced?
Also, I'm not familiar with the W3C process, but since this is a working draft, I'd assume they're invalid until the draft is finalized.
Then don't pull random statements out of your ass about it? What are accepted as standards spend most of their life as W3C working drafts. The W3C doesn't finalize a draft until the feature is obsolete, more or less.
WebWorkers, for example, is still a working draft. So is Web Storage.
The only thing that has ever mattered is browser support, not W3C specs.
This is not a Google project.
Registrant ID:mmr-87489
Registrant Name:DNS Admin
Registrant Organization:Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City:Mountain View
Registrant State/Province:CA
Registrant Postal Code:94043
Registrant Country:US
Registrant Phone:+1.6502530000
Registrant Phone Ext:
Registrant Fax: +1.6502530001
Registrant Fax Ext:
Registrant Email:dns-admin@google.com
The tech lead of the project is Malte Ubl who by their twitter page : @cramforce indicates that "I make www internet web pages for Google. "
Unless it's a 20% off time project (or a side project of some kind), I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee.
For the same way that tons of open/collaborative projects with multiple partners are not "X projects" even if they started and/or are hosted by X.
Heck, even something like Webkit is not an "Apple project"...
Downvotes? Are you kidding me? What part of "open source initiative" containing multiple industry leaders (like Twitter, and lots of others) don't people understand?
For something like SPDY/HTTP2 etc, I can say it's Google first and foremost (even if it got adoption later on).
For this not so much.
False. Google's slogan did not change.
Also the full slogan for Alphabet is "do the right thing – follow the law, act honorably, and treat each other with respect." This cannot be selfish & blatantly evil.
They never said it was? The web site just says AMP is open source (which it is). It says nothing about standards.
> Google could have easily promoted performance by applying penalties to heavy pages via Page Rank.
They have been since 2010: http://googlewebmastercentral.blogspot.com/2010/04/using-sit...
<amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work.
<amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks.
You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.
If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content.
In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs).
https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack
I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed.
What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :)
https://support.google.com/webmasters/topic/6001971
By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
see https://en.wikipedia.org/wiki/BPCS-Steganography
The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices.
The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility.
As you rightly point out there may be both vectors for either side which neither of us has thought of though.
It's the data sharing which is worrying. Exactly which entities have access to what data gathered by `ampproject.org`?
Two other points, and I hope these are received as constructive criticism.
1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us.
2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...".
Neither of these inspire confidence and I hope you can get at least one of them corrected soon.
[0]https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.or...
AMP is an open source project any publisher can use and tailor to their needs. If you don't want to factor Google into the solution then you don't have to.
But, keep on praising Facebook because you at least got their agenda right.
These are systems where the read/write ratios are often 1000:1.
Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated the symptoms by introducing caching servers and horizontal scaling.
In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is "free" for the publisher.
I don't understand how any "Engineer" can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.
About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…
As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved.
As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept.
build or host their own server-side analytics or commenting systems
I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.
Exactly! If that amount of work on server seems big, then realize that doing it client-side means dumping a million[0] times more work on the society, with all associated electricity usage.
[0] - literally; if you have 100k visitors and each visited you 10 times, that's 1M times the work that should actually have been done.
The question is this: what kind of overhead is a template rendering task (in js) for a modern browser, compared to the task of layout and rendering a finished html page? It will depend of course on the complexity of the data and the resulting page, as well as the browser, templating engine etc. I have no clue whether it's 1%, 10% or 50%.
JSON->HTML rendering may be only one step, but by not skipping it, we're making hundred thousands computers redo the computation that could be done once on a server. This has some electricity cost aggregated over all users, which we externalize to society because of a fad. You can't really skip the HTML->pixels step because of data size issues, but there's little excuse for client-side rendering of static content.
HTML is actually non-trivial to parse and isn't really optimized for anything.
Someone probably already developed that.
It feels slow ;)
Not very configurable though, can't really e.g. customise font size, observe the page or pass it through a screen reader.
That's where all the junk comes from: tracking the user and trying to upsell them into a mobile app so you can get more personal data and a spot on their home screen.
Its a lack of repsect for techies and quality and not understanding that the web is not a glossy brochure that you can't optimize by shouting at a printer over the phone.
OTOH...it turns out that so-called "static" content actually also requires quite a bit of processing. Apache (or whichever server you are using) is not exactly doing nothing. And it also turns out that this sort of processing is I/O heavy, which isn't exactly the fastest path on the machine, even if all the caching done by various entities (more processing) tries and mostly succeeds in making sure very little I/O actually takes place.
Add to that that moving data around nowadays is generally much more expensive than doing computation on it (several instructions per clock-cyle, multi-Gigahertz clocks, so well over a hundred clocks per main memory access, and millions per I/O, even with an SSD).
In short: if we re-examine our assumptions in light of a changing environment, might a well-optimized "dynamic" stack not be faster than a "static" one? (Compare: VoltDB...). And of course you could then cache the results in memory as well.
Static client side rendering at 1000:1 would mean that you could render an image file once and serve it to (at least) 1000 clients.
Yeees, and? Response CSS designs solve a lot of that with zero server-side computation overhead, and (compared to JS templating/render engines) minimal client-side overhead.
It's like shipping some intermediate bytecode doesn't seem to make sense, because every client needs to compile it, until you realize it allows you to ship one format that can even be used by many different architectures and even new architectures that didn't exist when you emitted the bytecode. At the cost of a second component that needs to be present on the machine to do the compiling.
When a vast majority of clients is the same or sufficiently similar, it may of course make sense to offer an optimized format, that requires less client-side processing But what would such an optimized format for the web be?
Where as with a static site, the complicated bit is only in the updates. A single server can handle massive numbers of requests and it's easy to scale further with a CDN.
I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO.
I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working overnight.
This looks like Trojans bearing gifts in my (maybe paranoid) mind.
One more pet peeve of mine: websites with giant non-scrolling banners at the top of the page. Thanks for wasting my screen space just so you can show your stupid website logo. As well as the pixel wastage, half the sites can't even make their banner stay still, it wobbles slightly as you scroll and it tries to reposition itself. Or, it breaks page scrolling - page up/page down will skip content hidden under the banner.
And while I'm moaning about the web of today: Also annoying are the sites that hide/shrink the banner as you scroll down the page, but make it pop back up as soon as you scroll upwards. If you accidentally move slightly too far down a page, you shift back up a row or two to catch a missing line of text, only to find a banner popping up and obscuring the bit that you specifically tried to view. Argh!
The specs for the various languages and the guidelines on their "best use" already define NOT doing any of those things either by dint of it not being built-in behavior or by already actively recommending against it. There's no need to follow a 2nd, proprietary specification to do what is already the standard.
This problem gets worse and worse :(
I also hate the trend to forcefully remap my old trusty middle mouse click from "open link in new tab" to "open link in current tab" via javascript.
This AMP project reduces the bloat but at the cost of increased privacy exposure. If I globally block `ampproject.org` when visiting a AMP-enabled web pages, the pages do not render at all.
My understanding is that now all "Google and its partners" have foiled the ability of visitors to protect their privacy with this AMP project -- and all these partners are given access to my browsing history.
This goes completely counter to "The Internet is for End Users"[2]. I hope people will boycott by blocking wholesale `ampproject.org` as 3rd party -- this needs to fail.
[1] Examples: `twitter.com`, `facebook.[com|net]`, `gravatar.com`, `fonts.googleapis.com`, etc.
I use Firefox with NoScript, which is definitely blocking the JS from ampproject.org. I also use Privacy Badger and uBlock Origin (thanks btw) and I'm not having any trouble at all. Here are the figures for the two pages I've tested with so far:
1- Visiting https://www.ampproject.org/how-it-works/ loads a perfectly readable page weighing 16.05kB in 40ms. It's just one file, the HTML document.
2- Visiting The Verge's demo page http://www.theverge.com/platform/amp/2015/10/7/9467149/googl... also loads a single perfectly readable HTML document weighing 17.6kB in 184ms.
I've used NoScript for quite a while and while I don't expect every page to work perfectly with it, the speed gains are incredible! AMP and NoScript aren't directly comparable but they seem to be accomplishing the same thing for me. Only one of them is also blocking third-party tracking and delivering feather-light pages which nearly always render acceptably.
Can you please clarify whether you mean the pages are totally blank, or if they just don't render the same as if you had allowed them to execute JS? (obviously if you globally block ampproject.org you can't access even their index.html page but that's not the info I'm after...)
In reality, the speed gain (which is the advertised benefit of AMP) is just a matter of avoiding to pull all the optional 3rd parties.
For example, a non-AMP random article from the same site[2], the page loads quite fast when I block all 3rd-party scripts/frames, except those from `vox-cdn.com` and `voxmedia.com`. The page renders fine -- with the virtuous "side effect" that 18 more 3rd-party are not logging network requests from my IP in their server logs (in this specific case).[3]
[1] https://cloud.githubusercontent.com/assets/585534/10397383/6...
[2] http://www.theverge.com/2015/10/9/9486505/california-calecpa...
[3] The total number of 3rd-party in this specific case climb to at least 48 without a blocker.
My only contribution to the conversation is utter bewilderment someone thought this would be a good idea.
The improvements are because they've removed everything.
Also, side note but I thought there was already a proposal in HTML for reusable elements?
What new is AMP bringing to the table? It seems to be some kind of a framework? Is it code or is it a preprocessor or what is it?
Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could adhere to so that their scripts behaved nicely.
I don't think it will necessarily fail, if AMP has a good ad story.
I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad blocking) and more behaved and subtle advertising, they will choose the latter.
Given that AMP is pushed by Google, it's pretty obvious that they did think about ads:
http://www.wsj.com/articles/what-googles-amp-project-means-f...
https://en.wikipedia.org/wiki/I-mode
Then, as now, regular HTML pages were considered too slow and complicated for mobile phones. I-mode was conceived by the large network operator NTT Docomo.
The big difference is that NTT Docomo were the exclusive gatekeepers for publishing content. Google also gives you the option of publishing AMP content on their CDN, but it's not mandatory.
If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads).
Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...
The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers that getting rid of all the bells and whistles will actually benefit them – and that if they don't do it, it will harm them because huge traffic drivers like Twitter won't put up with it anymore.
I dont think there is any innovation at all with either Facebook or Google, it's all about keeping the user on their service longer and by hosting the content themselves, they increase speed and claim more user time. It's a pure monopoly play with Apple, Google, Facebook having far more leverage than publishers (who have really none these days). Pubs need traffic to survive which is why they are willing to work with this, but the revenue potential is still up in the air so long-term sustainability is not anywhere near proven. I'm not convinced that this will work as a viable model, beyond the technical implementation.
http://www.nytimes.com/interactive/2015/10/01/business/cost-...
That Google et. al. are publishing a parallel framework to HTML indicates their goal is not just making mobile web faster, but in controlling that experience, to whatever end they may have in mind.
Isn't Google already claiming to demote sites that are slow to load, have content below the fold, etc?
I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it.
Sometimes a strong incentive is needed to change things.
This is such a great idea. Jerky web pages that jump around while you're trying to click on something are maddeningly annoying.
- You can't scroll to the top by tapping the status bar.
- The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail).
Anyone know how/why? I thought it might be some -webkit-overflow-scrolling trickery[2] with a full-size container div or something, but I don't see anything too weird like that.
[1] https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...
[2] https://css-tricks.com/snippets/css/momentum-scrolling-on-io...
EDIT: Turns out there is some -webkit-overflow-scrolling trickery going on[3]. But again, why?
[3] https://github.com/ampproject/amphtml/blob/77d9f31263866e56a...
In general though, why sites feel the need to change / reimplement scrolling is beyond me. Every reimplementation is worse than the native behaviour.
[0] https://github.com/ampproject/amphtml/blob/master/src/viewpo...
It also ads the permanent url bar at the top and the navigational arrows at the bottom. This is useful for some web apps, because if those weren't permanent, you couldn't have buttons fixed on the bottom. This is because when you would click them, the back/forward arrows bar would appear pushing your button up so you have to click it again.
I used to use it but I've stopped because it's a whole level of complexity on your complex app.
I wish iOS safari scrolling would feel like native. Many people are using this property for this reason only, sacrificing screen space (the always-on browser interface). It used to be worse with the small screen of the iPhone 4.
Neither AMP nor ad blocking are what is needed. We need sensible ads that are unobtrusive. We need web pages that do not track the consumer. We need smarter designs that don't use huge images everywhere. We need JS where it is needed and not just because it's cool.
We don't need two behemoths fighting over the control of our web.
We had WML for mobile devices before mobile devices were powerful enough to render HTML. Then we got smartphones better than my computer bought 5 years ago. AMP in my oppinion is a step back, yes you can do a lot of things in CSS. But in reality there are cases where it needs to happen dynamically. For example: javascript input validation, you cannot validate data using CSS. Are we then going to reinvent Javascript using some new fancy name?. Also, how about backwards compatibility(IE7-8 I'm looking at you)?
Those companys could spend their resources on better things, like implementing ways to load viewport dependent images(it seems it's already done using picture tag). Because multimedia takes huge chunk of the website.
And like always there are ways to write performant websites using existing technology and even more ways to write slow websites using all the "bleeding edge" technology. It's up to the developer mostly.
Why not define an actual subset of HTML? You know, like XHTML Strict Mode?
Why must everything be a JavaScript library?!
JavaScript is used to implement custom elements, like amp-image. That's just how custom elements work.
Disqualifying custom elements from an HTML subset would be like claiming function declarations can't be in subsets of JavaScript.
To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information).
Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter.
The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information.
As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web".
The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users.
I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback.
Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need.
To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.
To pretend that the infrastructure that allows companies to pay for the content I want to consume is incidental to the true purpose of the web (text documents??) is pretty narrow.
Even so their crappy webfonts took like 1-2 seconds with a FOIT before that, while all the text was available almost immediately.
Who does already know EVERYTHING about your users? But can they sell it?
startup idea: Make a blazingly fast CMS that tracks everything and show pretty graphs.
The Internet and all of its neutral standards are being eviscerated by faceless avarice, and no one gives a shit.
I was rendering WML/CHTML/XHTML with Wurfl depending on UAs from hacked ASP.NET.
Then iPhone appeared and ruined everything ;)