Breaking the 1000ms Time to Glass Mobile Barrier
Why Hacker News recommends it
It is cited for the cost of network round trips and mobile latency limits.
What it is
Ilya Grigorik of Google's Make the Web Fast team explains how to build a mobile site that appears on screen within one second. He covers the network and rendering constraints on mobile.
Recommended by 0 HN commenters across 0 different months, 2014 to 2018.
What Hacker News said
Cites alialkhatib · 2014-05 · on “Stop the Slow Lane”
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 no
Cites warfangle · 2014-06 · on “Human JavaScript”
> "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 o
Cites bsimpson · 2018-01 · on “A letter about Google AMP”
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 ass