Your browser could do the preloading, AMP or not. I believe they tried it once and it breaks a lot of crappy Enterprise intranet apps. For that to work web sites must respect REST: no state changes for Get requests.
Browsers don’t preload links by default to avoid that sort of breakage, but there are rel=preload and rel=prefetch tags that pages can use to direct that behavior, which is supported by at least Chrome and Firefox. The AMP documentation seems to suggest that AMP gets its preloading behavior (in part? entirely?) by auto-inserting these tags in appropriate places. Is there something else I’m missing here for why other pages/frameworks couldn’t also insert these tags to get similar behavior?
On a diverse web, you would visit different origins, each having a different experience. Now compare this to Facebook, where every piece of content looks the same, coming from all over the web, yet flattened into a dull timeline. You don’t get to experience the home of that content, just the content itself.
I’m not sure what you’re getting at here. Are you implying that Medium has a realistic chance of supplanting Facebook as the dominant sinkhole of people’s attention?
The person you replied to pointed out Medium, like Facebook, was killing diversity in a specific way. You brought up that Medium isnt as dominant, which was an orthogonal point. I countered that one by showing you cant rely on that to begin with givin the dominant sites started as high-growth, small players most didnt think would become dominant.
So, it was a site that hurt diversity which could also become more popular with more damage. Better to avoid them early.
Facebook wouldn’t be killing diversity if it wasn’t the most dominant sinkhole of attention ever created in human history. There’s plenty of room for large players as long as one of them isn’t completely taking over.
The worst thing about Facebook is that it’s a walled garden (and always has been, unlike Medium) and that it’s so dominant that there are people who think it is the Internet.
My understanding of AMP is that the technical limitations it imposes (compared to a regular HTML/JS webpage) is exactly for this purpose: Be able to cache on CDN is one thing, but more importantly be able to preload pages at will.
The author makes a good point by saying that Google has an advantage because while you’re spending time browsing the Google’s page (or Google assistant or else on Android), it can perform all those pre-fetching in the background.
But to be 100% accurate, I don’t think this statement is fully true:
Taking that page from 2–8s to instant performance is something only Google is capable of, because it is the only entity in the world controlling the most important information portal: search.
Apple on iOS devices, or Microsoft on Windows, or RandomDev on “MyCoolNewsApps”, or a Firefox add-on, or Facebook could do it too, or even the NYTimes on their own website.
But to date only Google has spent the time/$ writing the AMP clients.
And given enough time spent on the platform, caching on any Google CDN AMP server, or even any AMP cache server could be unnecessary, as long as the prefetching algorithm is smarter than you and predict all the pages you want to read before you tap on the link to read them.
The most important requirement for AMP pages to be successfully perceived as fast is that you spend a lot of time on the platform (or the platform has the capability of pre-fetching with close to perfect accuracy in the background)
Preloading is exclusive to AMP. Google does not preload non-AMP pages. If Google would have a genuine interest in speeding up the whole web on mobile, it could simply preload resources of non-AMP pages as well.
As qznc mentions, there might exist some technical limitation of non AMP pages that prevents this from happening.
And with AMP pages Google can guarantee that the pages sizes are small enough and not too stressing on compute. It would piss off users really fast if Chrome started to preload multi Mb / java script heavy pages without the users consent, draining both data usage and battery.
Your browser could do the preloading, AMP or not. I believe they tried it once and it breaks a lot of crappy Enterprise intranet apps. For that to work web sites must respect REST: no state changes for Get requests.
Browsers don’t preload links by default to avoid that sort of breakage, but there are rel=preload and rel=prefetch tags that pages can use to direct that behavior, which is supported by at least Chrome and Firefox. The AMP documentation seems to suggest that AMP gets its preloading behavior (in part? entirely?) by auto-inserting these tags in appropriate places. Is there something else I’m missing here for why other pages/frameworks couldn’t also insert these tags to get similar behavior?
Funny how this blog post is hosted on Medium…
Medium has nowhere close to the reach of Facebook.
“The Facebook has nowhere close the reach of Myspace.”
I’m not sure what you’re getting at here. Are you implying that Medium has a realistic chance of supplanting Facebook as the dominant sinkhole of people’s attention?
The person you replied to pointed out Medium, like Facebook, was killing diversity in a specific way. You brought up that Medium isnt as dominant, which was an orthogonal point. I countered that one by showing you cant rely on that to begin with givin the dominant sites started as high-growth, small players most didnt think would become dominant.
So, it was a site that hurt diversity which could also become more popular with more damage. Better to avoid them early.
Facebook wouldn’t be killing diversity if it wasn’t the most dominant sinkhole of attention ever created in human history. There’s plenty of room for large players as long as one of them isn’t completely taking over.
The worst thing about Facebook is that it’s a walled garden (and always has been, unlike Medium) and that it’s so dominant that there are people who think it is the Internet.
So if it is preloading everything on a search result page, it means my data bill is going up for things I will not even look at.
i mean you’re already using http so what’s another order of magnitude of useless data really
My understanding of AMP is that the technical limitations it imposes (compared to a regular HTML/JS webpage) is exactly for this purpose: Be able to cache on CDN is one thing, but more importantly be able to preload pages at will.
The author makes a good point by saying that Google has an advantage because while you’re spending time browsing the Google’s page (or Google assistant or else on Android), it can perform all those pre-fetching in the background.
But to be 100% accurate, I don’t think this statement is fully true:
Apple on iOS devices, or Microsoft on Windows, or RandomDev on “MyCoolNewsApps”, or a Firefox add-on, or Facebook could do it too, or even the NYTimes on their own website. But to date only Google has spent the time/$ writing the AMP clients.
And given enough time spent on the platform, caching on any Google CDN AMP server, or even any AMP cache server could be unnecessary, as long as the prefetching algorithm is smarter than you and predict all the pages you want to read before you tap on the link to read them.
The most important requirement for AMP pages to be successfully perceived as fast is that you spend a lot of time on the platform (or the platform has the capability of pre-fetching with close to perfect accuracy in the background)
As qznc mentions, there might exist some technical limitation of non AMP pages that prevents this from happening. And with AMP pages Google can guarantee that the pages sizes are small enough and not too stressing on compute. It would piss off users really fast if Chrome started to preload multi Mb / java script heavy pages without the users consent, draining both data usage and battery.