Breaking the 1000ms Time to Glass Mobile Barrier

As I understand it, a round-trip request on a mobile network can be very expensive [0]. One of the ways that AMP enables sites to load instantly-upon-click is by starting those requests in the background. (Then, when the user clicks, it's just a matter of bringing the IFRAME into view - no network involved.) Loading a traditional site can have side effects (e.g. reporting a view to an advertiser's analytics). By using the AMP validator, Google Search knows it's safe to preload and prerender an article, without triggering side-effects like analytics. So it's more than just loading faster than some threshold; it needs to be safe to cache and prerender the content. The AMP validator is what asserts these are both safe. (Note, I don't work on AMP and don't represent Google - this is my personal understanding.) [0] Ilya Grigorik's time-to-glass talk ▶ this video

> "What about load times and performance?!?!" If you're rendering everything on the client like that, how many HTTP requests are you making, other than the initial 3 (stylesheet + javascript + html document)? I'm especially focusing on mobile performance, here. On 3G you have 200-2500ms latency on the control plane, 200ms latency for dns lookup, 200ms latency on establishishing a tcp connection, your TLS handshake will have a latency anywhere from 200-400ms and the actual http request will have a latency of 200ms. That's 1000-2900ms per http request, minus 100 if your client can cache DNS responses (and everything is on the same domain). Sometimes these will be multiplexed. You can't count on it though. 4G is only marginally better: you have an overhead of 240-500ms on 4G. And none of that takes into account the time it takes your server to process a request, or the time it takes for the client to parse and execute your rendering codebase. If you're aiming for sub-1000ms request-to-glass, you can't follow the advice of this book (don't render anything on the server ever) - unless you don't mind the client showing a loading animation for the 2-15 seconds it'll take to load your "app." (good luck with that mobile bounce rate) 0. ▶ this video

I don't think this is the right approach. I realize that the principle is fundamentally the same with SOPA protests (depriving users of content to highlight the danger of this passing), but there's a more salient argument that you could make here if you really wanted. Why not implement a loading bar that actually progressed slowly and then put a brief explanation underneath the loading bar describing the FCC "slow lane" and how it would negatively impact users? To add insult to injury, give the user 3 options: - pay the site owner to access the "fast lane" to your content - send an email (to FCC chair? maybe a representative?) to voice their anger - get used to waiting; that'll be the new norm if nobody prevents this, right? The first option would be incredibly controversial, but would underscore how objectionable the "Slow Lane" idea even is. If anyone is stubborn enough to pay, you could funnel that money into the EFF or some other relevant organization. The point is that just throwing people a loading screen (especially without a good explanation) will leave the user confused. Once the content loads they'll probably forget about that loading screen anyway (at least on a conscious level), so don't wait until afterward to explain what just happened. As an aside, there was a comment that users will wait for a website that's sufficiently highly trafficked, but I don't think that's true. I remember some Google presentation[0] where an engineer explained that virtually any extra