One detail which I feel must be mentioned: if you block `ampproject.org` by default -- directly or by blocking 3rd-party javascript by default, -- you will be "punished" with a 8-second delay before the page becomes visible.
This is an entirely artificial delay, implemented through an inlined style CSS animation in AMP-based pages:
animation:-amp-start 8s steps(1,end) 0s 1 normal both}
@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
I can't see any good reason for such delay. If you are not aware of this 8s delay, you might be misled into thinking the page is broken and that `ampproject.org` is really needed, while the page renders just fine without it, except for the delay.
This kind of dishonest design is all too common now. If you pull back the curtain, you can find all sorts of other ways that the user is gaslighted.
One example is that the youtube mobile website will prevent you from playing a video in the background now. It didn't used to. This is to "encourage" you to use their Youtube RED app.
Really impressed! Took a quick look at page source, a couple of observations on why it's fast:
1. Plain, small html - page size is 6.1 kb (request took 700ms for me, I guess the server side rendering is pretty fast too), css file 11kb; note html, css and js are all properly minified
2. Font-awesome and jquery at the bottom of page to not block page rendering, both loaded throught cdn (although a fallback jQuery exists)
3. Site's own js is only 5.6k
4. No large static assets, only image on page is an svg dlogo
5. Did not check with js off, but saw hints of decent fallbacks for no-script
Sadly it seems you can't register new accounts anymore because of their merger(?) with VisualPing, but their old site still functions for those with accounts and the speed is mindblowing as you can see there. I feel every website should strive to be like this.
lobste.rs is usually pretty fast but they have a silly and annoying April fools thing going on right now. I once did a dive into their CSS to see how they were doing collapsible tree style comments without any JS whatsoever.
The first point in the article is the dead killer of AMP for me. My mobile provider gives me very little monthly data, I've stopped using AMP because preloading the AMP results is eating through my cap, with images disabled.
Without preloading, AMP is slower than the non-AMP version of the same webpage with a simple script blocker. And usually causing more traffic too.
I hope Google refrains from bullying website owners into making the internet a worse experience for people without 1GB+ data plan.
So basically Google could get 90% of what AMP provides without AMP itself, because the magic is in the caching and forcibly reducing the ad junk the page loads.
Which is made clear in the AMP documentation itself.
The AMP project isn't pretending they're bringing something unprecedented to the web... they're very open about the fact that most of the things you need to do to make your site "AMP compatible" are just speed-conscious best-practices (like only using CSS transitions that have hardware acceleration, or async loading of assets).
yes they basically broken internet the same way it was broken with wap, including broken sharing and deeplinking, for no good reason at all... well except to run amp you need to run it on their resources and all your users are now profiled across all websites...
Heh. This reminds me of a recent pet peeve and observation of mine: progressive web apps are not faster.
The Twitter Lite PWA, arguably the 'flagship' PWA ("developed in partnership with Google"), takes longer to display tweets for me than regular desktop Twitter.com, and the old 'static' mobile twitter site (which loads INSTANTLY[1] you can only get with user agent trickery)
[1] Just did some testing. According to Chrome Dev Tools, old Twitter Mobile displays tweets in 124ms. PWA Twitter takes greater than 1.4s (it stopped recording screenshots), 2s according to a screen recording https://gfycat.com/PlushThornyIcefish
PWAs aren't literally faster — caching aside, they load the same data and it takes the same amount of time over the same connection. But there is a percieved performance boost if the PWA uses caching and preloading intelligently. The first load might take a little longer, loading the first tweets will take just as long, but scrolling through the timeline should be faster and page transitions can be almost instantaneous.
So nowadays 61 requests per page load is considered an "accelerated" page? Might not be so bad with http2 but still wow. Maybe publishers should start working on that number if they want actually faster web pages.
It depends on if you pack your data or not, really
With simple development on a moderate website you might have a couple of html resources, a few css files and some js files to fetch, not to mention all the media (images, videos and audio).
It's easily half that just by doing sane development where you split functionality into files and if your site is media rich it's not surprising at all.
A very low quality article. The whole point of AMP is to define a restricted subset of HTML that is safe to prerender and still provide working analytics to the publisher. When you prerender, the advantage of AMP is substantial as it is impossible to beat a user experience of instant, which is why users prefer it and why publishers go through the trouble of implementing two web versions of their web pages (in addition to Facebook and Apple News non-web versions).
The point of the AMP cache is not for CDN speed, as the author mistakenly believed and measured, but for same-origin or CORS prerender, and Google is not the only implementer.
AMP is a cancer on search results. The purpose of a search engine is to provide the best links it can to content related to a user’s search. The search engine should not be providing the content of the search result as a primary link. Having a backup cache of the link is fine in case it changes or disappears. It’s the responsibility of the original site to be able to serve its visitors.
I think the point of AMP is it gives Google a simple and reliable way to detect fast rendering pages that render well on mobile in a way that can't be easily gamed. When you allow unrestricted usage of JavaScript that's changing page content, loading styles etc. for example, detecting pages like this is more difficult.
You can write performant pages without AMP but how would Google reliably detect pages like this?
I'm not saying AMP is the best solution and I can see why some developers have objections against it but I think I understand what it's trying to do.
The same way it reliable detects the content of the site and everything else. Take a snapshot and keep the latest history.
You can easily change the content on a page with javascript so Google still needs to load everything to get an accurate representation. Since there are plenty of tools already (including Google's own) that measure page loading speed, it would be trivial to combine them into a performance score for search rankings.
If speed was actually made into a strong signal, major websites would've become as fast as AMP within months.
The most infuriating part of AMP for me is that I can't count the number of times I'd read an AMP version of an article, and graphics in it were just plain missing without any heads up. Why newspapers and the like would gimp their own work like that is beyond me.
Created a site in pure AMP. All competitors didn't use AMP then (1 yr ago). My site was the fastest, didn't have any ads, was the lightest, the most beautiful, had the best UX flow.
SEO-wise my site still doesn't list on the keywords which are in H1 and the page title but all the crappy, non-AMP, megabytes big slow-loading, ads-heavy competitor sites are still in the top ten SERP.
Guess that even Google stopped giving AMP sites any special rank power except they are news sites (then you will see them probably in the carousel but only if they are accepted with Google News).
Isn't it in Google's best interest to list the ad heavy sites first? They don't receive any commission sending users to your ad free site, but they'll earn 32% of AdSense profits from your competitors.
Now, I don't believe that is actually occurring, but it's one of the many ways that our interests and Google's interests do not align.
Do you want to hack into your spouse's phone remotely without touching his or her phone
You can hack into any devices to access facebook , whastapp , text mssg , call logs etc
to know who they have been talking to and if they're cheating on you
remotecyberhacker@ gmail com
he's the fastest,reliable and cost-effective you can ever come across cos his name has never been SOILED , in shrot....he's the best working for me .
text/call ; + 1 3 4 7 89 93 01 7
whatsapp ; +1 267 52 6 53 4 6
Is it really hard to use the whole of my screen? I'm well aware that modern websites have to scale to lots of different screen sizes. My laptop is a 17" job so why the blazes do I only get to see a block of text using the middle third of it? It looks shit. I'd probably have to peek under the lenses of my specs on a smaller screen. I spend far too much time using CTRL + these days.
See http://bettermotherfuckingwebsite.com/ for the reasoning behind this trend. Line width, namely the number of characters shown in one, is regarded as a prime factor in readability, which I personally agree with.
it's funny how so many people use to ridiculed ColdFusion and Asp.Net WebForms for "re-inventing" and "polluting" HTML with their custom tags and server components respectively. This is exactly what AMP is.
[+] [-] gorhill|8 years ago|reply
This is an entirely artificial delay, implemented through an inlined style CSS animation in AMP-based pages:
I can't see any good reason for such delay. If you are not aware of this 8s delay, you might be misled into thinking the page is broken and that `ampproject.org` is really needed, while the page renders just fine without it, except for the delay.Example: https://ampbyexample.com/
[+] [-] apostacy|8 years ago|reply
One example is that the youtube mobile website will prevent you from playing a video in the background now. It didn't used to. This is to "encourage" you to use their Youtube RED app.
[+] [-] emilfihlman|8 years ago|reply
[+] [-] Ajedi32|8 years ago|reply
[+] [-] Shorel|8 years ago|reply
https://forum.dlang.org/
[+] [-] yiransheng|8 years ago|reply
1. Plain, small html - page size is 6.1 kb (request took 700ms for me, I guess the server side rendering is pretty fast too), css file 11kb; note html, css and js are all properly minified
2. Font-awesome and jquery at the bottom of page to not block page rendering, both loaded throught cdn (although a fallback jQuery exists)
3. Site's own js is only 5.6k
4. No large static assets, only image on page is an svg dlogo
5. Did not check with js off, but saw hints of decent fallbacks for no-script
[+] [-] rolae|8 years ago|reply
A government site, lightning fast, try the search! No bullshit design.
[+] [-] Waterluvian|8 years ago|reply
[+] [-] mehrdadn|8 years ago|reply
Sadly it seems you can't register new accounts anymore because of their merger(?) with VisualPing, but their old site still functions for those with accounts and the speed is mindblowing as you can see there. I feel every website should strive to be like this.
[+] [-] tylerl|8 years ago|reply
[+] [-] bramjans|8 years ago|reply
[+] [-] throwaway_80bf3|8 years ago|reply
https://lobste.rs
[+] [-] tzahola|8 years ago|reply
[+] [-] tscs37|8 years ago|reply
Without preloading, AMP is slower than the non-AMP version of the same webpage with a simple script blocker. And usually causing more traffic too.
I hope Google refrains from bullying website owners into making the internet a worse experience for people without 1GB+ data plan.
[+] [-] niutech|8 years ago|reply
[+] [-] ep103|8 years ago|reply
[+] [-] xenadu02|8 years ago|reply
Does that about sum it up?
[+] [-] fastball|8 years ago|reply
The AMP project isn't pretending they're bringing something unprecedented to the web... they're very open about the fact that most of the things you need to do to make your site "AMP compatible" are just speed-conscious best-practices (like only using CSS transitions that have hardware acceleration, or async loading of assets).
[+] [-] notatoad|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] LoSboccacc|8 years ago|reply
[+] [-] madeofpalk|8 years ago|reply
The Twitter Lite PWA, arguably the 'flagship' PWA ("developed in partnership with Google"), takes longer to display tweets for me than regular desktop Twitter.com, and the old 'static' mobile twitter site (which loads INSTANTLY[1] you can only get with user agent trickery)
[1] Just did some testing. According to Chrome Dev Tools, old Twitter Mobile displays tweets in 124ms. PWA Twitter takes greater than 1.4s (it stopped recording screenshots), 2s according to a screen recording https://gfycat.com/PlushThornyIcefish
[+] [-] Veen|8 years ago|reply
[+] [-] niutech|8 years ago|reply
[+] [-] vemv|8 years ago|reply
Each Google search would download dozens of MBs and produce a significant CPU workload, both resources being precious on mobile.
Perhaps it was a communication issue: AMP should have been named/marketed "preloadable pages" rather than "fast pages".
[+] [-] niutech|8 years ago|reply
[+] [-] Too|8 years ago|reply
[+] [-] emilfihlman|8 years ago|reply
With simple development on a moderate website you might have a couple of html resources, a few css files and some js files to fetch, not to mention all the media (images, videos and audio).
It's easily half that just by doing sane development where you split functionality into files and if your site is media rich it's not surprising at all.
[+] [-] lern_too_spel|8 years ago|reply
The point of the AMP cache is not for CDN speed, as the author mistakenly believed and measured, but for same-origin or CORS prerender, and Google is not the only implementer.
[+] [-] millstone|8 years ago|reply
As an iOS user I find AMP to be quite buggy, and AMP versions of pages like reddit are borderline non-functional. I don't prefer it at all.
[+] [-] geuis|8 years ago|reply
[+] [-] seanwilson|8 years ago|reply
You can write performant pages without AMP but how would Google reliably detect pages like this?
I'm not saying AMP is the best solution and I can see why some developers have objections against it but I think I understand what it's trying to do.
[+] [-] JoshMnem|8 years ago|reply
It's appifying the WWW on Google's domain and allowing them to dictate how sites are monetized. On the most basic level, it isn't motivated by speed.
[+] [-] manigandham|8 years ago|reply
The same way it reliable detects the content of the site and everything else. Take a snapshot and keep the latest history.
You can easily change the content on a page with javascript so Google still needs to load everything to get an accurate representation. Since there are plenty of tools already (including Google's own) that measure page loading speed, it would be trivial to combine them into a performance score for search rankings.
If speed was actually made into a strong signal, major websites would've become as fast as AMP within months.
[+] [-] dmitriid|8 years ago|reply
Google already has the tools to detect fast rendering pages, though they've more or less stopped talking about them after the introduction of AMP.
[+] [-] buro9|8 years ago|reply
Your web browsing isn't it at all.
If you are on an Android phone go install NetGuard and take a look at the logs.
There are a few domains that come up for almost every app:
1. graph.facebook.com
2. graph.accountkit.com
3. .crashlytics.com
4. .ampproject.net
5. .segment.io
AMP Project is up there. The majority of the apps on my phone now do their content via WebView + AMP.
In this AMP have found their niche.
[+] [-] kmfrk|8 years ago|reply
[+] [-] niutech|8 years ago|reply
[+] [-] waytogo|8 years ago|reply
Created a site in pure AMP. All competitors didn't use AMP then (1 yr ago). My site was the fastest, didn't have any ads, was the lightest, the most beautiful, had the best UX flow.
SEO-wise my site still doesn't list on the keywords which are in H1 and the page title but all the crappy, non-AMP, megabytes big slow-loading, ads-heavy competitor sites are still in the top ten SERP.
Guess that even Google stopped giving AMP sites any special rank power except they are news sites (then you will see them probably in the carousel but only if they are accepted with Google News).
[+] [-] Guest9812398|8 years ago|reply
Now, I don't believe that is actually occurring, but it's one of the many ways that our interests and Google's interests do not align.
[+] [-] yorby|8 years ago|reply
[+] [-] niutech|8 years ago|reply
[+] [-] gregoryjenny100|8 years ago|reply
[+] [-] notatoad|8 years ago|reply
(the bars are raw/cached/canonical, and the groups on the X axis are min/max/median/90th)
[+] [-] soulchild37|8 years ago|reply
https://danluu.com/
[+] [-] tuananh|8 years ago|reply
[+] [-] gerdesj|8 years ago|reply
[+] [-] rileyphone|8 years ago|reply
[+] [-] thrownaway954|8 years ago|reply
[+] [-] stevew20|8 years ago|reply