16 ms·

Neither PWA nor AMP are needed to make a website load fast

313 points by Scarbutt 8y ago

Spivak 8y ago
Well yeah but the author is missing the point: these tools allow your site to load faster than the theoretical limit without them. AMP buys you Google's CDN and prefetching on Search. And PWA buys you a 0 distance cache hit on your second visit, the ability to prefetch unvisited resources, and with the ability to update the cache in the background. Not saying these aren't negligible on a 15MB site but they are tools for making an existing slow site appear faster which is what everyone who isn't a dev really wants.
- berbec 8y ago
  Right, but why is your site 15MB anyway?
  - AlexCoventry 8y ago
    It's a client-side neural net?
- dvtrn 8y ago
  on a 15MB site Good lord, friend. Why put your users through this to begin with?
  - osrec 8y ago
    If it's just a website, then I agree that is indeed excessive. If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable, and probably a good candidate to be a PWA. I know a lot of people hate the idea of doing everything in the browser, but seriously, it's the one ubiquitous platform that we have, which even competing entities have agreed to standardise. I personally think it will be the most popular app delivery mechanism in the next few years, even on mobile devices.
    - dvtrn 8y ago
      If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable You either have an abundance of high speed internet access, or benefit from internet usage that isn't metered by the amount of data consumed, or both. Functionality or not, heavy web experiences leave out a lot of people who would otherwise be willing and capable users of %product% if it weren't for the excessive payloads they're often expected to consume just to be a user when that payload could quite trivially be reduced and still accomplish the goal of delivering content and information to the end user. So here's my question: forget about people who hate doing everything in the browser, what about the users who just don't have access to Cable+ internet speeds, want to use the product, but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element because the browser is all this user is familiar with? Not everyone on the internet is a regular of HackerNews who groks native applications versus web apps. At what point do we start focusing on the content and asking ourselves "Do I REALLY need this animation library just to indicate 'Start here' is where they should be interacting with my webform"? To answer that rhetorical question for you: probably, quite likely not.
      - zdragnar 8y ago
        > but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element? Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Sadly, these aren't going to get to experience a decent chunk of the internet anyway, since video, gifs, and images all frequently weigh significantly more when put together.
        dvtrn 8y ago
        Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Since when did forms become useless and what web-based video editor are you (or the original reply-er) pointing to that uses AMP?
  - sazfedjhrgnukc 8y ago
    Exactly! There can never be any reason whatsoever for any site anywhere on the entire World Wide Web to be 15MB. Absolutely not! I mean, I don't even know what the site does, but 15MB can not possibly be justified.
  - lightedman 8y ago
    You'd be amazed. Accessing my game via the web results in a couple gig (varying, depends on world state) download. My music tools, if they were put on the internet, would result in needing to load about 300 MB of stuff. And that's very, VERY tightly coded and hand-optimized, with no JS, Java, etc.
- metildaa 8y ago
  This assumes that Google's CDN is providing a significant advantage in connectivity, when in actuality you'll often have more available bandwidth between say OVH and your ISP at peak times, as compared to relying on Google's congested peering to certain large ISPs. Amazon S3 can be really paimfully slow at peak times too, I often see sub-1MB/s, while fast.com (Netflix) or OVH can fill the pipe.
  - ec109685 8y ago
    Google can preload and pre render amp sites because the specification ensures they are safe to do so. You can’t do that with your own website.
osrec 8y ago
But you do need "PWA" if you want your site to work offline. PWAs were never really sold as something that would make your site's initial load time faster. Not really sure how the author got that impression. It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.
- GhostVII 8y ago
  The author mentions that, and says there is a use case there, but suggests that most PWA's don't have any use when offline, so they are useless in lots of cases.
- starik36 8y ago
  Can't you just use ServiceWorkers in a regular webpage? Seems like you can. That would allow you to have an offline persistent website while still using a webpage. https://caniuse.com/#feat=serviceworkers https://caniuse.com/#feat=serviceworkers
  - Technetium_Hat 8y ago
    So the thing that makes a site a PWA in your eyes is the "add $app to your homescreen" prompt? Because I would view any site that works offline, beyond http/s caching, to be a PWA.
    - NightlyDev 8y ago
      The definition of a PWA is a page that uses features like add to homescreen, service workers... or push notifications. It doesn't have to use this and the browser doesn't have to support it. PWA will progressively use such features when they are supported, and that's where the name comes from. If a page requires these things to function then it's not a PWA.
  - osrec 8y ago
    There seems to be a few misconceptions around what is and what isn't a PWA. A PWA (in my opinion) is simply a website that makes use of certain browser features (e.g. service workers, push notifications, manifests). It's a bad definition, with a lot of grey areas, but it is what it is (and let's face it, definitions in web development are often hard to pin down). For example, we built https://usebx.com/app https://usebx.com/app with plain old HTML, JavaScript and CSS. Yet, it can be installed on your phone, send you push notifications and even works offline. So I would categorise it as a PWA rather than a website. My point is, if you're using service workers, you're more a PWA than a standard website.
askaboutit 8y ago
Wikipedia is a static delivery website. Of course it’s easy if all you’re delivering is static content. Try that with an ecommerce site where dynamic information is sent from sometimes multiple sources. It’s better to load it once and have a reactive site call just the necessary apis after. Calling everything over and over again in eCommerce is a pain for users. Unless you can afford a database and servers to be distributed globally to counter the added latency of downloading everything again and again. PWA is the next step for that. But, yeah, ok, for Wikipedia you can be static as you want.
- viraptor 8y ago
  Unless you have a very active community commenting and interacting around the items, you can definitely go almost entirely static, even in ecommerce. Regenerate pages after changes happen and you'll be fine. You'll still need dynamic search most likely, but even those can be pre-generated for many terms. (Your admin / content management part needs to be dynamic of course, but that's not customer-visible) If your catalogue is so large that constant regeneration is impractical, you can generate on-demand and cache long-term a few layers above for anything not requested recently.
  - briandear 8y ago
    > You'll still need dynamic search most likely, but even those can be pre-generated for many terms. Have you ever worked on a high scale e-commerce site? I have and what you are talking about is impractical and pretty much impossible. Products have multiple variants, photos for each variant. Various companion products that depend on what you already selected. Pricing options that can depend on quantities or packages. And search? Spend 5 minutes on any serious e-commerce search system and there is no such thing as “common search terms.” Of course there are common searches, but on any non-trivial e-commerce system, you have potentially thousands of distinct common searches. I was one of the original engineers for https://www.matalan.co.uk https://www.matalan.co.uk and you can’t just “regenerate” pages after changes. You can regenerate the cache for images or product descriptions, but e-commerce isn’t like a printed catalog. We put exceptional engineering into that application and to trivialize that sort of application like it was some kind of blog site kind of demonstrates a lack of experience in building something that serves millions of visitors per month — visitors that all have different paths based on what they want to buy.
tyingq 8y ago
It's not the hype that has publishers moving to AMP. It's not wanting to be dropped out of the carousel. Shame if somethin' were to happen to yer website traffic, friend.
- ravenstine 8y ago
  Having worked for a publisher, it's definitely carousel FOMO. Some of it is the Google hype, but the carousel is 90% of it.
lern_too_spel 8y ago
This guy doesn't know what AMP does. AMP is a subset of HTML that can be validated safe to prerender. That means instant page loads for the user, not merely fast.
- smadge 8y ago
  What do you mean by “safe to prerender?”
  - lern_too_spel 8y ago
    User isn't deanonymized to the publisher, publisher analytics and ads don't register page views, page can be trivially transformed to lazy load below the fold, etc.
- tyingq 8y ago
  The outside bits of a Trojan horse are attractive for a reason.
  - lern_too_spel 8y ago
    It is the only available solution to a real problem. If you have a better solution, by all means, be a hero. Meanwhile, the rest of the search and content aggregation industry has gone with AMP, which works today.
    - untog 8y ago
      > the rest of the search and content aggregation industry has gone with AMP Because Google effectively gave them no choice.
      - lern_too_spel 8y ago
        > Because Google effectively gave them no choice. I'm talking about link aggregators and search engines, not publishers. They could have come up with another solution, but they decided to use AMP, which provides the same benefits to them as it provides to Google.
Solar19 8y ago
The author says you can do these things anyway without AMP, but what he doesn't get is that web developers were not doing them. It took the nudge of AMP to get decent performance on the mobile web. He also failed to mention a key AMP rule: all CSS is in the head, a max of 50 KB. There is no external CSS at all. That's crucial. It reverses a persistent anti-pattern in web development that calls for a bunch of separate files for CSS and JS. Almost all CSS on most webpages is unused (this is still true of a lot of AMP sites -- 50 KB is way too much CSS for an article). I think the reality here is that early 21st-century web developers are terrible at web development. They stuff massive amounts of JS and CSS down users throats, distributed across 50 or a 100 requests, and call themselves "engineers". AMP, or something even better, needs to be the default way to build websites.
- writepub 8y ago
  While everything you note is true, it's hardly the fault of the engineers. One cannot expect engineers to hand code css and optimize every time. These things should be handled by tools. With the advent of css-in-js and compilers, this is slowly but surely happening. What amp did was prove at scale, and with tooling, that performance can be achieved. That philosophy is dripping into other tools.
  - spiralganglion 8y ago
    In some cases, sure, it's not the fault of engineers — if an engineer is in an environment where they're not able to take the time to do things right. In some cases, it is the lack of tools. But I think it's often not either of those, and it is in fact the chosen priorities of the engineers. A lack of attention to craft. We see a similar split in GameDev. Some game developers (Carmack, Blow, Acton) sweat every millisecond and byte and cache hit. If you work on engines in AAA, that's a job requirement. Others are happy to use Unity (etc), never optimize, and don't mind that their simple 2d platformer is bloated and wastes cycles. But many simply don't care — why spend time cutting down on bloat and waste when the game plays well enough. I see plenty of engineers who have a "it works, ship it" mentality. To me, that's not the attitude of someone who cares about their craft.
deleted 8y ago
[deleted]
androidgirl 8y ago
I agree on AMP, you can just pack less JS and be done with it. But AMP is REALLY about rich search results online. Google creates more interactive search results for AMP pages than non-AMP versions. As for PWA's, I'm honestly a fan, to a certain limit. I really like Gatsby.js, especially because the rendered pages work with Javascript disabled. Django/Rails/$FRAMEWORK with Turbolinks.js is also great, for the same reason I like pwa's. If you aren't a fan of the JS ecosystem (totally fair), Turbolinks is a great way to get some ""snappyness".
- lern_too_spel 8y ago
  Microdata is for rich search results. AMP is for instant (not fast, as the author mistakenly stated) loading from a search results page or content aggregator.
  - androidgirl 8y ago
    True! But Google incorporates more microdata from AMP pages in Search results (as in more fields), or at the least their Rich Search Results documentation makes it out to be that way. I may be wrong, this just was my understanding from reading all the Google search guides last week.
- benbristow 8y ago
  Not a fan of Turbolinks really. Usually one of the things I remove in a default Rails install. Just means JavaScript stuff needs to be re-init every page load etc and means extra messing about to get stuff to work
pandapower2 8y ago
>I’m not saying practices promoted by AMP are bad or useless. They are good practices. But nothing stops you from following them in the regular web. Disagree. The most important feature of AMP is that it makes it impossible to add the kind of bloated crap that causes poor performance on something like a large media company website. Something like a news website likely has 2-4+ analytics integrations, and a similar number of ad provider integrations. Your staff want to use google analytics so that goes in. Your display ad provider (ads appearing in the page around articles) uses some other analytics provider so they have to go in. You want video ads so another ad provider who requires a video specific analytics provider goes in. Site rankings produced by someone or other are important to get direct ad sales so their required analytics integration goes in. Then someone in sales signs some deal to add a third party widget to your homepage so that goes in. All of this happens over the protestations of the developers. People may literally quit over these integrations but their replacement will implement it. Turn off your ad blocker, go to a news site, watch the network tab and despair. AMP makes that crap near enough to impossible that the developers can convince the sales team and management that it simply cannot be done.
- deleted 8y ago
  [deleted]
- dmitriid 8y ago
  I’ve yet to find an AMP page that downloads less than 1MB of crap for what edsentially id a dtatic text page (sometimes with images).
  - pandapower2 8y ago
    1 MB is incredibly compact by news site standards. Try a random article page like https://edition.cnn.com/2018/12/07/tech/australia-encryption-law-passes-intl/index.html https://edition.cnn.com/2018/12/07/tech/australia-encryption... I refreshed a few times, scrolling to the bottom of the page each time. According to Chrome dev tools even without a video playing between 6 MB and 21 MB was transferred just for me to scroll to the bottom of the page.
naikrovek 8y ago
I agree with the article author. Performance today is not a priority for web developers. It's not even in the top ten priorities. Performance is just not considered unless it is so bad that a site looks like it isn't working. We can change this at any point we like. We won't. It will continue to get worse.
- Romanulus 8y ago
  It's a shame since all hardware is getting slower and slower every day.
  - naikrovek 8y ago
    That kind of thinking is why people STILL wait on computers to do things that could be SO MUCH faster. Why the hell does it take an application like Photoshop 30 fucking seconds to simply launch and get to where it can accept input on my 32-core, dual-Xeon desktop at work with 192GB of RAM and a very fast SSD? Because people punt the fucking problem into the future and assume everything will just continually get faster
scotchio 8y ago
You don't need AMP if you want to make your website load fast, but you do need AMP if you want mobile SEO organic clicks.
cheeaun 8y ago
The footnotes mentioned: > By the way, since you first opened this article my ServiceWorker has downloaded XXX Mb of useless data in background. I hope you are on WiFi :) But the code doesn't really download anything. It stores the intial datetime your first load the page, and diff to the current time, convert it to "bytes" every second.
- omeid2 8y ago
  http://tonsky.me/sw.js http://tonsky.me/sw.js: "Totally legit ServiceWorker ES6 implementation";
- nmca 8y ago
  Yeah I was pissed off about this, then very amused when I checked. I think his point is, that's what news sites often do on your phone!
robinanil 8y ago
At Tock we had been obsessed with page load performance since the beginning and I agree with the author. We avoided PWA mostly due to it's broken behavior. Often times we are faster than loading the same restaurant page on Google search. Out challenge has been that we have to load a lot of images, so we spent a lot of time optimizing everything around it and optimizing everything around it. From TLS1.3 to the CDN, to every part of our stack. Try it out https://www.exploretock.com https://www.exploretock.com https://www.exploretock.com/tfl https://www.exploretock.com/tfl
- robinanil 8y ago
  Also ours is not a static page, it has dynamic content, and ga + fb tracking for our restaurants and we make it work by correctly prioritizing important rendering elements over other
  - robinanil 8y ago
    We have also spent time reducing the initial JS parsing size by chunking out our ever growing JS bundle and we constantly test on slow devices on 2g/3g profiles to emulate bad internet conditions. We have learned a lot in the process probably good for a blog post
- 43920 8y ago
  Sort of off-topic, but there seems to be a bug with the way search results work. If I click on "search", it shows me an option for "<my city name> nearby", but if I click on that, I get results for a city that has the same name, but is in a completely different area. edit: this also applies to the "near you" cards on the home page.
  - robinanil 8y ago
    Thanks, could be a geocoder issue for a specific city - we will investigate.
- mychael 8y ago
  Very fast indeed. Hard work paid off!
ridiculous_fish 8y ago
AMP is embarrassingly buggy on iOS. The address bar doesn't hide properly, rotation breaks things, the "original link" often triggers the address bar, find highlighting is busted, and Reader Mode often fails. AMP links are often slower than Reader Mode, because they're blocked on slow font loading.
geuis 8y ago
AMP is a fucking cancer on the web right now. When you visit what you expect to be a search result url, it should take you to the server/site that was indexed. When AMP for launched, it didn’t even provide a link to the original site. It took a lot of people like me grousing and complaining before Google’s 17 tiers of product managers had enough meetings to even budge on that. I honestly can’t tell you how so many sites were convinced to implement AMP on their sites. I could wave my hands and say everyone is stupid and just goes along with the latest shiny bullshit but that can’t be but a small part of the actual answer. Supposedly Google isn’t factoring AMP pages into their search rankings yet, but given the positive signal of page speed (a good thing, generally) and them switching to a mobile first index, a natural direct side effect is that AMP pages will be ranked higher by default. If Google were somehow automatically transforming sites you’d never hear the end of people complaining, especially content owners. Instead they convinced engineers and content creators to tie the rope on the hanging post themselves, jump off, and be happy about it. I can’t speak too negatively of PWA. The ability to build offline web apps is actually pretty useful in some situations. Overall I still firmly believe that a good search engine should deliver the most relevant links or content for what is being queried. Should a bad QA site get ranked higher than a high quality one just because the former delivers mobile-first AMP pages and the latter has a slightly bigger payload but has much more relevant content?
tylerjwilk00 8y ago
Author has good points about PWAs. I love PWAs because I hate giving native apps access to my phone's data but the emphasis on offline support for PWAs does seem off point. It has Web in the name. You probably need internet access!
ksec 8y ago
I hate Service Worker. It literally provides a tools for website to abuse and judging from the trend things will be much worst in the next few years.
AngeloAnolin 8y ago
Want to load fast? Load less.
scoot_718 8y ago
In my experience AMP makes a website not load, until it times out and redirects to the non-AMP.
xte 8y ago
Hem... To make a website faster... Make a website! Not a webcrap with tons of "framework", tons of stuff loaded from third parties etc you'll get a skyrocketing high speed.
deleted 8y ago
[deleted]
juskrey 8y ago
Though we can find a lot of obvious overengineering cases, Tonsky should have known better that reference-style website a la Wiki and feature rich application like Airbnb impose very different trade offs between initial/overall loading times and functionality. An interesting case when someone who is firmly saying "BS" three times in every paragraph is BS too.
- ForHackernews 8y ago
  How is Airbnb a "feature rich application" compared to Wikipedia? They're both Search+CRUD sites as far as I can see.
  - juskrey 8y ago
    Wikipedia user experience is basically a tree, Airbnb is a pretty complex graph
    - ForHackernews 8y ago
      Wikipedia has editors, varying levels of admin permissions, different types of pages, templates, comments, edits, etc. I'm not sure their data model is any less complicated than Airbnb. But regardless of the complexity of the database schema, neither one of them is really an "feature rich application" in the way that that say, Photoshop, is a feature rich application. At the end of the day, I think they're both just CRUD apps.
countryqt30 8y ago
All our websites actually performed 1) faster without AMP and 2) AMP loves to break your entire website regularly. So it's relatively useless. Google, first test your code before you publish it, please.
deepakkarki 8y ago
It's true, that with static sites you're better off without any JS. It's pretty much how I've built https://discoverdev.io https://discoverdev.io It's powered by a home grown static site generator framework. Hosted on Netlify. Works fairly fast even random corners of India. But then I found my own generator limiting and surveyed existing frameworks - decided to go with Gatsby - a ReactJS based SSG. To my surprise Gatsby+Netlify worked much faster and smoother than my JS free solution! It's currently running at https://beta.discoverdev.io https://beta.discoverdev.io Worth noting that Gatsby generates pure html+css during build time, and page renders fine without JS enabled. Seems to be a good balance between DevX and UX. :)
- _eric 8y ago
  Minor thing I noticed on your site: a clean load is requesting around 425kb of data, but your /assets/img/dd-logo.ico alone weighs 362kb. Same thing happens in your new site. Maybe it's something to look into, reducing the size of it should make your site even faster.
  - deepakkarki 8y ago
    Oh thanks, I didn't notice :) I guess I can compress a lot further, given it should be a tiny (34x34?) image anyway!
aethertron 8y ago
In defense of PWA, specifically the value of offline-availability: > You can’t call Uber while being offline, and why would you open Uber app otherwise? To see my journey history. Uber has this data. It's my data, why shouldn't it be on my device too? > Tinder is useless offline. You can’t date empty chat screens. I could look at my messages offline, if they were saved on the device. > You can’t join a meetup at Meetup.com without network connection. But I could look at my calendar and see upcoming stuff for the days ahead, see past events, my message history, and profiles for my groups. All this stuff loading from a local cache could improve speed. But that's just a bonus.
auct 8y ago
Why it's so funny Netflix recently found out that if they remove 500 Kb of JavaScript from a static (!!!) webpage it will load WAY faster I loled a lot:)
edem 8y ago
Definitely true. What you need is less js and more content. My site loads so fast that it even works in a forest where there is only EDGE available.
donohoe 8y ago
I’ve seen many cases where AMP version of an article was slower to load than the regular web version.
goofballlogic 8y ago
I too struggle to like AMP. The rhetoric seems a little absent imagination in regard to offline. Are you really saying your handheld computer can't be useful without a worldwide network connection?
jillesvangurp 8y ago
Amp is not about making your site fast but about making sure that sites aggregated in e.g. Google News are all predictably fast by constraining what they can do. It's not about making the individual sites fast but making sure that none of them are needlessly slow by imposing constraints. Similarly PWA is also not about performance but about adding metadata that phones and browsers can use to treat the site like an app by e.g. giving it an icon in an app folder. You couldn't do this before, now you can. Before people were doing silly things like packaging up websites as apps and putting them in the app store just so they could their own cute little icon in somebody's app folder. Now they don't have to do that and the install/discovery is a bit smoother as well (easier discovery, less steps, less users lost).
- blablabla123 8y ago
  No idea how Amp actually works, I always thought that one component about it was acting like a CDN for common frameworks. PWAs are much easier to tune for global performance though if you have a tight budget. The app doesn't have to talk much to a Backend server and (down)loading can be tuned by using a CDN.
- jjulius 8y ago
  >... but making sure that none of them are needlessly slow by imposing constraints. Anecdotally, AMP sites always load a bit slower for me. The page will sit blank for a few seconds before finally dumping all of the content at once, as opposed to loading text immediately while it takes a moment to load the rest of the content that has a higher file-size. Without AMP, I can start reading a page before it's done loading. With AMP, especially on a desktop, I'm often stuck staring at a white screen for 15-20 seconds before anything shows up. I often find myself trying to cut the "amp" bit out of the URL to see if I can get to the original page. It's frustrating, and it is a big part of why I'm considering dumping Google as a search engine. That's just my experience, though - YMMV.
  - ayoisaiah 8y ago
    AMP on the desktop? Don't think I've seen that before. I've only seen AMP links on mobile and I don't think it's returned in desktop search results
aceon48 8y ago
Lol this guy's site took over 10 seconds to load on my mobile. Invalidates anything he had to say
- rchaud 8y ago
  Ever heard of the HN "hug of death"? Sites load slower if there are a high number of concurrent connections at the time you're trying to visit.
fipple 8y ago
The headline is analogous to “Antitrust laws are not needed to prevent price fixing.” Treated as a statement of fact, it’s technically true, but it’s really a statement of policy opinion, whose weaknesses are clear.
liuyanghejerry 8y ago
The article is with prejudice somehow. You still need lots of apps which working perfectly with offline mode. For example reading books you already downloaded, watching movies you already downloaded, or whatever immutable content you already have. The author choose to making examples with apps that demands communications with outside world instantly, which makes the whole point weak.
gambler 8y ago
Google is steadily undermining the foundational principles of the web that made the platform so popular and allowed Google to do searching in the first place. The scary part is that they don't just offer an "alternative" technology like ActiveX, Flash, Applets, Silverlight and so on. They are influencing core web standards.
codedokode 8y ago
I tried to look at an example AMP page here [1]. When loading with an empty cache, it loads 5.5 Mb of files. I don't see where are the optimizations. It uses a custom font. Custom fonts are absolutely unnesessary for a news page; they only delay the moment when text becomes visible. Standard Windows fonts are of a good quality and don't need a replacement (which often renders very poorly on Windows XP). It uses a lot of scripts. Script block some browsers while parsing and executing. It has SVG images embedded into the page. If you want the page to load faster, you should move images into external files. AMP is directly linked to Google and cannot be used without it. Please look at the requirements for AMP HTML documents: [2] > AMP HTML documents MUST ... contain a <script async src="https://cdn.ampproject.org/v0.js"></script> https://cdn.ampproject.org/v0.js"></script> tag inside their head tag. So every AMP document MUST load a Google-controlled script. And by the way, it contains 12 000 lines when beautified. It contains different Google URLs like 'https://ampcid.google.com/v1/publisher:getClientId?key=' https://ampcid.google.com/v1/publisher:getClientId?key=' or 'https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKtqGxnoeIqVM33Uf7hRSa3GJxuzR7mLc' https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKt... , references to Doubleclick and AdSense (but not other ad networks). Does every site need it? It contains a lot of code not necessary for most websites. For example, a XHR interceptor for "some trusted AMP viewers" [3] is included into the script. Or a cryptographic library for calculating sha hashes [4]. You can use only JS components approved by Google; the spec says: > Extended components > The script URL must start with https://cdn.ampproject.org https://cdn.ampproject.org So for example, Google might make a custom component for Facebook but not for QQ or Mixi. Google defines what widget can appear on an AMP page. If you are an ad network, you have to make negotiations with Google to be added (you have to negotiate with your competitor). If US government imposes sanctions on some foreign site, Google will have to comply. It is clearly a technology made for integrating news articles into a Google page (and judging by limitations in the spec, Google might plan to make a non-vebview native renderer for AMP pages). Don't believe when they try to pretend that it can be used independently as a standard or made for accelerating the web. [1] https://amp.theguardian.com/us-news/commentisfree/2016/feb/16/thomas-piketty-bernie-sanders-us-election-2016 https://amp.theguardian.com/us-news/commentisfree/2016/feb/1... [2] https://www.ampproject.org/docs/fundamentals/spec https://www.ampproject.org/docs/fundamentals/spec [3] https://github.com/ampproject/amphtml/issues/11294 https://github.com/ampproject/amphtml/issues/11294 [4] https://github.com/ampproject/amphtml/blob/master/src/service/crypto-impl.js https://github.com/ampproject/amphtml/blob/master/src/servic...

313 points by Scarbutt 8y ago

Well yeah but the author is missing the point: these tools allow your site to load faster than the theoretical limit without them. AMP buys you Google's CDN and prefetching on Search. And PWA buys you a 0 distance cache hit on your second visit, the ability to prefetch unvisited resources, and with the ability to update the cache in the background. Not saying these aren't negligible on a 15MB site but they are tools for making an existing slow site appear faster which is what everyone who isn't a dev really wants.

berbec 8y ago
Right, but why is your site 15MB anyway?
- AlexCoventry 8y ago
  It's a client-side neural net?
dvtrn 8y ago
on a 15MB site Good lord, friend. Why put your users through this to begin with?
- osrec 8y ago
  If it's just a website, then I agree that is indeed excessive. If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable, and probably a good candidate to be a PWA. I know a lot of people hate the idea of doing everything in the browser, but seriously, it's the one ubiquitous platform that we have, which even competing entities have agreed to standardise. I personally think it will be the most popular app delivery mechanism in the next few years, even on mobile devices.
  - dvtrn 8y ago
    If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable You either have an abundance of high speed internet access, or benefit from internet usage that isn't metered by the amount of data consumed, or both. Functionality or not, heavy web experiences leave out a lot of people who would otherwise be willing and capable users of %product% if it weren't for the excessive payloads they're often expected to consume just to be a user when that payload could quite trivially be reduced and still accomplish the goal of delivering content and information to the end user. So here's my question: forget about people who hate doing everything in the browser, what about the users who just don't have access to Cable+ internet speeds, want to use the product, but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element because the browser is all this user is familiar with? Not everyone on the internet is a regular of HackerNews who groks native applications versus web apps. At what point do we start focusing on the content and asking ourselves "Do I REALLY need this animation library just to indicate 'Start here' is where they should be interacting with my webform"? To answer that rhetorical question for you: probably, quite likely not.
    - zdragnar 8y ago
      > but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element? Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Sadly, these aren't going to get to experience a decent chunk of the internet anyway, since video, gifs, and images all frequently weigh significantly more when put together.
      - dvtrn 8y ago
        Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Since when did forms become useless and what web-based video editor are you (or the original reply-er) pointing to that uses AMP?
- sazfedjhrgnukc 8y ago
  Exactly! There can never be any reason whatsoever for any site anywhere on the entire World Wide Web to be 15MB. Absolutely not! I mean, I don't even know what the site does, but 15MB can not possibly be justified.
- lightedman 8y ago
  You'd be amazed. Accessing my game via the web results in a couple gig (varying, depends on world state) download. My music tools, if they were put on the internet, would result in needing to load about 300 MB of stuff. And that's very, VERY tightly coded and hand-optimized, with no JS, Java, etc.
metildaa 8y ago
This assumes that Google's CDN is providing a significant advantage in connectivity, when in actuality you'll often have more available bandwidth between say OVH and your ISP at peak times, as compared to relying on Google's congested peering to certain large ISPs. Amazon S3 can be really paimfully slow at peak times too, I often see sub-1MB/s, while fast.com (Netflix) or OVH can fill the pipe.
- ec109685 8y ago
  Google can preload and pre render amp sites because the specification ensures they are safe to do so. You can’t do that with your own website.

osrec 8y ago

But you do need "PWA" if you want your site to work offline. PWAs were never really sold as something that would make your site's initial load time faster. Not really sure how the author got that impression. It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.

GhostVII 8y ago
The author mentions that, and says there is a use case there, but suggests that most PWA's don't have any use when offline, so they are useless in lots of cases.
starik36 8y ago
Can't you just use ServiceWorkers in a regular webpage? Seems like you can. That would allow you to have an offline persistent website while still using a webpage. https://caniuse.com/#feat=serviceworkers https://caniuse.com/#feat=serviceworkers
- Technetium_Hat 8y ago
  So the thing that makes a site a PWA in your eyes is the "add $app to your homescreen" prompt? Because I would view any site that works offline, beyond http/s caching, to be a PWA.
  - NightlyDev 8y ago
    The definition of a PWA is a page that uses features like add to homescreen, service workers... or push notifications. It doesn't have to use this and the browser doesn't have to support it. PWA will progressively use such features when they are supported, and that's where the name comes from. If a page requires these things to function then it's not a PWA.
- osrec 8y ago
  There seems to be a few misconceptions around what is and what isn't a PWA. A PWA (in my opinion) is simply a website that makes use of certain browser features (e.g. service workers, push notifications, manifests). It's a bad definition, with a lot of grey areas, but it is what it is (and let's face it, definitions in web development are often hard to pin down). For example, we built https://usebx.com/app https://usebx.com/app with plain old HTML, JavaScript and CSS. Yet, it can be installed on your phone, send you push notifications and even works offline. So I would categorise it as a PWA rather than a website. My point is, if you're using service workers, you're more a PWA than a standard website.

askaboutit 8y ago

Wikipedia is a static delivery website. Of course it’s easy if all you’re delivering is static content. Try that with an ecommerce site where dynamic information is sent from sometimes multiple sources. It’s better to load it once and have a reactive site call just the necessary apis after. Calling everything over and over again in eCommerce is a pain for users. Unless you can afford a database and servers to be distributed globally to counter the added latency of downloading everything again and again. PWA is the next step for that. But, yeah, ok, for Wikipedia you can be static as you want.

viraptor 8y ago
Unless you have a very active community commenting and interacting around the items, you can definitely go almost entirely static, even in ecommerce. Regenerate pages after changes happen and you'll be fine. You'll still need dynamic search most likely, but even those can be pre-generated for many terms. (Your admin / content management part needs to be dynamic of course, but that's not customer-visible) If your catalogue is so large that constant regeneration is impractical, you can generate on-demand and cache long-term a few layers above for anything not requested recently.
- briandear 8y ago
  > You'll still need dynamic search most likely, but even those can be pre-generated for many terms. Have you ever worked on a high scale e-commerce site? I have and what you are talking about is impractical and pretty much impossible. Products have multiple variants, photos for each variant. Various companion products that depend on what you already selected. Pricing options that can depend on quantities or packages. And search? Spend 5 minutes on any serious e-commerce search system and there is no such thing as “common search terms.” Of course there are common searches, but on any non-trivial e-commerce system, you have potentially thousands of distinct common searches. I was one of the original engineers for https://www.matalan.co.uk https://www.matalan.co.uk and you can’t just “regenerate” pages after changes. You can regenerate the cache for images or product descriptions, but e-commerce isn’t like a printed catalog. We put exceptional engineering into that application and to trivialize that sort of application like it was some kind of blog site kind of demonstrates a lack of experience in building something that serves millions of visitors per month — visitors that all have different paths based on what they want to buy.

tyingq 8y ago

It's not the hype that has publishers moving to AMP. It's not wanting to be dropped out of the carousel. Shame if somethin' were to happen to yer website traffic, friend.

ravenstine 8y ago
Having worked for a publisher, it's definitely carousel FOMO. Some of it is the Google hype, but the carousel is 90% of it.

lern_too_spel 8y ago

This guy doesn't know what AMP does. AMP is a subset of HTML that can be validated safe to prerender. That means instant page loads for the user, not merely fast.

smadge 8y ago
What do you mean by “safe to prerender?”
- lern_too_spel 8y ago
  User isn't deanonymized to the publisher, publisher analytics and ads don't register page views, page can be trivially transformed to lazy load below the fold, etc.
tyingq 8y ago
The outside bits of a Trojan horse are attractive for a reason.
- lern_too_spel 8y ago
  It is the only available solution to a real problem. If you have a better solution, by all means, be a hero. Meanwhile, the rest of the search and content aggregation industry has gone with AMP, which works today.
  - untog 8y ago
    > the rest of the search and content aggregation industry has gone with AMP Because Google effectively gave them no choice.
    - lern_too_spel 8y ago
      > Because Google effectively gave them no choice. I'm talking about link aggregators and search engines, not publishers. They could have come up with another solution, but they decided to use AMP, which provides the same benefits to them as it provides to Google.

Solar19 8y ago

The author says you can do these things anyway without AMP, but what he doesn't get is that web developers were not doing them. It took the nudge of AMP to get decent performance on the mobile web. He also failed to mention a key AMP rule: all CSS is in the head, a max of 50 KB. There is no external CSS at all. That's crucial. It reverses a persistent anti-pattern in web development that calls for a bunch of separate files for CSS and JS. Almost all CSS on most webpages is unused (this is still true of a lot of AMP sites -- 50 KB is way too much CSS for an article). I think the reality here is that early 21st-century web developers are terrible at web development. They stuff massive amounts of JS and CSS down users throats, distributed across 50 or a 100 requests, and call themselves "engineers". AMP, or something even better, needs to be the default way to build websites.

writepub 8y ago
While everything you note is true, it's hardly the fault of the engineers. One cannot expect engineers to hand code css and optimize every time. These things should be handled by tools. With the advent of css-in-js and compilers, this is slowly but surely happening. What amp did was prove at scale, and with tooling, that performance can be achieved. That philosophy is dripping into other tools.
- spiralganglion 8y ago
  In some cases, sure, it's not the fault of engineers — if an engineer is in an environment where they're not able to take the time to do things right. In some cases, it is the lack of tools. But I think it's often not either of those, and it is in fact the chosen priorities of the engineers. A lack of attention to craft. We see a similar split in GameDev. Some game developers (Carmack, Blow, Acton) sweat every millisecond and byte and cache hit. If you work on engines in AAA, that's a job requirement. Others are happy to use Unity (etc), never optimize, and don't mind that their simple 2d platformer is bloated and wastes cycles. But many simply don't care — why spend time cutting down on bloat and waste when the game plays well enough. I see plenty of engineers who have a "it works, ship it" mentality. To me, that's not the attitude of someone who cares about their craft.

deleted 8y ago

[deleted]

androidgirl 8y ago

I agree on AMP, you can just pack less JS and be done with it. But AMP is REALLY about rich search results online. Google creates more interactive search results for AMP pages than non-AMP versions. As for PWA's, I'm honestly a fan, to a certain limit. I really like Gatsby.js, especially because the rendered pages work with Javascript disabled. Django/Rails/$FRAMEWORK with Turbolinks.js is also great, for the same reason I like pwa's. If you aren't a fan of the JS ecosystem (totally fair), Turbolinks is a great way to get some ""snappyness".

lern_too_spel 8y ago
Microdata is for rich search results. AMP is for instant (not fast, as the author mistakenly stated) loading from a search results page or content aggregator.
- androidgirl 8y ago
  True! But Google incorporates more microdata from AMP pages in Search results (as in more fields), or at the least their Rich Search Results documentation makes it out to be that way. I may be wrong, this just was my understanding from reading all the Google search guides last week.
benbristow 8y ago
Not a fan of Turbolinks really. Usually one of the things I remove in a default Rails install. Just means JavaScript stuff needs to be re-init every page load etc and means extra messing about to get stuff to work

pandapower2 8y ago

>I’m not saying practices promoted by AMP are bad or useless. They are good practices. But nothing stops you from following them in the regular web. Disagree. The most important feature of AMP is that it makes it impossible to add the kind of bloated crap that causes poor performance on something like a large media company website. Something like a news website likely has 2-4+ analytics integrations, and a similar number of ad provider integrations. Your staff want to use google analytics so that goes in. Your display ad provider (ads appearing in the page around articles) uses some other analytics provider so they have to go in. You want video ads so another ad provider who requires a video specific analytics provider goes in. Site rankings produced by someone or other are important to get direct ad sales so their required analytics integration goes in. Then someone in sales signs some deal to add a third party widget to your homepage so that goes in. All of this happens over the protestations of the developers. People may literally quit over these integrations but their replacement will implement it. Turn off your ad blocker, go to a news site, watch the network tab and despair. AMP makes that crap near enough to impossible that the developers can convince the sales team and management that it simply cannot be done.

deleted 8y ago
[deleted]
dmitriid 8y ago
I’ve yet to find an AMP page that downloads less than 1MB of crap for what edsentially id a dtatic text page (sometimes with images).
- pandapower2 8y ago
  1 MB is incredibly compact by news site standards. Try a random article page like https://edition.cnn.com/2018/12/07/tech/australia-encryption-law-passes-intl/index.html https://edition.cnn.com/2018/12/07/tech/australia-encryption... I refreshed a few times, scrolling to the bottom of the page each time. According to Chrome dev tools even without a video playing between 6 MB and 21 MB was transferred just for me to scroll to the bottom of the page.

naikrovek 8y ago

I agree with the article author. Performance today is not a priority for web developers. It's not even in the top ten priorities. Performance is just not considered unless it is so bad that a site looks like it isn't working. We can change this at any point we like. We won't. It will continue to get worse.

Romanulus 8y ago
It's a shame since all hardware is getting slower and slower every day.
- naikrovek 8y ago
  That kind of thinking is why people STILL wait on computers to do things that could be SO MUCH faster. Why the hell does it take an application like Photoshop 30 fucking seconds to simply launch and get to where it can accept input on my 32-core, dual-Xeon desktop at work with 192GB of RAM and a very fast SSD? Because people punt the fucking problem into the future and assume everything will just continually get faster

scotchio 8y ago

You don't need AMP if you want to make your website load fast, but you do need AMP if you want mobile SEO organic clicks.

cheeaun 8y ago

The footnotes mentioned: > By the way, since you first opened this article my ServiceWorker has downloaded XXX Mb of useless data in background. I hope you are on WiFi :) But the code doesn't really download anything. It stores the intial datetime your first load the page, and diff to the current time, convert it to "bytes" every second.

omeid2 8y ago
http://tonsky.me/sw.js http://tonsky.me/sw.js: "Totally legit ServiceWorker ES6 implementation";
nmca 8y ago
Yeah I was pissed off about this, then very amused when I checked. I think his point is, that's what news sites often do on your phone!

robinanil 8y ago

At Tock we had been obsessed with page load performance since the beginning and I agree with the author. We avoided PWA mostly due to it's broken behavior. Often times we are faster than loading the same restaurant page on Google search. Out challenge has been that we have to load a lot of images, so we spent a lot of time optimizing everything around it and optimizing everything around it. From TLS1.3 to the CDN, to every part of our stack. Try it out https://www.exploretock.com https://www.exploretock.com https://www.exploretock.com/tfl https://www.exploretock.com/tfl

robinanil 8y ago
Also ours is not a static page, it has dynamic content, and ga + fb tracking for our restaurants and we make it work by correctly prioritizing important rendering elements over other
- robinanil 8y ago
  We have also spent time reducing the initial JS parsing size by chunking out our ever growing JS bundle and we constantly test on slow devices on 2g/3g profiles to emulate bad internet conditions. We have learned a lot in the process probably good for a blog post
43920 8y ago
Sort of off-topic, but there seems to be a bug with the way search results work. If I click on "search", it shows me an option for "<my city name> nearby", but if I click on that, I get results for a city that has the same name, but is in a completely different area. edit: this also applies to the "near you" cards on the home page.
- robinanil 8y ago
  Thanks, could be a geocoder issue for a specific city - we will investigate.
mychael 8y ago
Very fast indeed. Hard work paid off!

ridiculous_fish 8y ago

AMP is embarrassingly buggy on iOS. The address bar doesn't hide properly, rotation breaks things, the "original link" often triggers the address bar, find highlighting is busted, and Reader Mode often fails. AMP links are often slower than Reader Mode, because they're blocked on slow font loading.

geuis 8y ago

AMP is a fucking cancer on the web right now. When you visit what you expect to be a search result url, it should take you to the server/site that was indexed. When AMP for launched, it didn’t even provide a link to the original site. It took a lot of people like me grousing and complaining before Google’s 17 tiers of product managers had enough meetings to even budge on that. I honestly can’t tell you how so many sites were convinced to implement AMP on their sites. I could wave my hands and say everyone is stupid and just goes along with the latest shiny bullshit but that can’t be but a small part of the actual answer. Supposedly Google isn’t factoring AMP pages into their search rankings yet, but given the positive signal of page speed (a good thing, generally) and them switching to a mobile first index, a natural direct side effect is that AMP pages will be ranked higher by default. If Google were somehow automatically transforming sites you’d never hear the end of people complaining, especially content owners. Instead they convinced engineers and content creators to tie the rope on the hanging post themselves, jump off, and be happy about it. I can’t speak too negatively of PWA. The ability to build offline web apps is actually pretty useful in some situations. Overall I still firmly believe that a good search engine should deliver the most relevant links or content for what is being queried. Should a bad QA site get ranked higher than a high quality one just because the former delivers mobile-first AMP pages and the latter has a slightly bigger payload but has much more relevant content?

tylerjwilk00 8y ago

Author has good points about PWAs. I love PWAs because I hate giving native apps access to my phone's data but the emphasis on offline support for PWAs does seem off point. It has Web in the name. You probably need internet access!

ksec 8y ago

I hate Service Worker. It literally provides a tools for website to abuse and judging from the trend things will be much worst in the next few years.

AngeloAnolin 8y ago

Want to load fast? Load less.

scoot_718 8y ago

In my experience AMP makes a website not load, until it times out and redirects to the non-AMP.

xte 8y ago

Hem... To make a website faster... Make a website! Not a webcrap with tons of "framework", tons of stuff loaded from third parties etc you'll get a skyrocketing high speed.

deleted 8y ago

[deleted]

juskrey 8y ago

Though we can find a lot of obvious overengineering cases, Tonsky should have known better that reference-style website a la Wiki and feature rich application like Airbnb impose very different trade offs between initial/overall loading times and functionality. An interesting case when someone who is firmly saying "BS" three times in every paragraph is BS too.

ForHackernews 8y ago
How is Airbnb a "feature rich application" compared to Wikipedia? They're both Search+CRUD sites as far as I can see.
- juskrey 8y ago
  Wikipedia user experience is basically a tree, Airbnb is a pretty complex graph
  - ForHackernews 8y ago
    Wikipedia has editors, varying levels of admin permissions, different types of pages, templates, comments, edits, etc. I'm not sure their data model is any less complicated than Airbnb. But regardless of the complexity of the database schema, neither one of them is really an "feature rich application" in the way that that say, Photoshop, is a feature rich application. At the end of the day, I think they're both just CRUD apps.

countryqt30 8y ago

All our websites actually performed 1) faster without AMP and 2) AMP loves to break your entire website regularly. So it's relatively useless. Google, first test your code before you publish it, please.

deepakkarki 8y ago

It's true, that with static sites you're better off without any JS. It's pretty much how I've built https://discoverdev.io https://discoverdev.io It's powered by a home grown static site generator framework. Hosted on Netlify. Works fairly fast even random corners of India. But then I found my own generator limiting and surveyed existing frameworks - decided to go with Gatsby - a ReactJS based SSG. To my surprise Gatsby+Netlify worked much faster and smoother than my JS free solution! It's currently running at https://beta.discoverdev.io https://beta.discoverdev.io Worth noting that Gatsby generates pure html+css during build time, and page renders fine without JS enabled. Seems to be a good balance between DevX and UX. :)

_eric 8y ago
Minor thing I noticed on your site: a clean load is requesting around 425kb of data, but your /assets/img/dd-logo.ico alone weighs 362kb. Same thing happens in your new site. Maybe it's something to look into, reducing the size of it should make your site even faster.
- deepakkarki 8y ago
  Oh thanks, I didn't notice :) I guess I can compress a lot further, given it should be a tiny (34x34?) image anyway!

aethertron 8y ago

In defense of PWA, specifically the value of offline-availability: > You can’t call Uber while being offline, and why would you open Uber app otherwise? To see my journey history. Uber has this data. It's my data, why shouldn't it be on my device too? > Tinder is useless offline. You can’t date empty chat screens. I could look at my messages offline, if they were saved on the device. > You can’t join a meetup at Meetup.com without network connection. But I could look at my calendar and see upcoming stuff for the days ahead, see past events, my message history, and profiles for my groups. All this stuff loading from a local cache could improve speed. But that's just a bonus.

auct 8y ago

Why it's so funny Netflix recently found out that if they remove 500 Kb of JavaScript from a static (!!!) webpage it will load WAY faster I loled a lot:)

edem 8y ago

Definitely true. What you need is less js and more content. My site loads so fast that it even works in a forest where there is only EDGE available.

donohoe 8y ago

I’ve seen many cases where AMP version of an article was slower to load than the regular web version.

goofballlogic 8y ago

I too struggle to like AMP. The rhetoric seems a little absent imagination in regard to offline. Are you really saying your handheld computer can't be useful without a worldwide network connection?

jillesvangurp 8y ago

Amp is not about making your site fast but about making sure that sites aggregated in e.g. Google News are all predictably fast by constraining what they can do. It's not about making the individual sites fast but making sure that none of them are needlessly slow by imposing constraints. Similarly PWA is also not about performance but about adding metadata that phones and browsers can use to treat the site like an app by e.g. giving it an icon in an app folder. You couldn't do this before, now you can. Before people were doing silly things like packaging up websites as apps and putting them in the app store just so they could their own cute little icon in somebody's app folder. Now they don't have to do that and the install/discovery is a bit smoother as well (easier discovery, less steps, less users lost).

blablabla123 8y ago
No idea how Amp actually works, I always thought that one component about it was acting like a CDN for common frameworks. PWAs are much easier to tune for global performance though if you have a tight budget. The app doesn't have to talk much to a Backend server and (down)loading can be tuned by using a CDN.
jjulius 8y ago
>... but making sure that none of them are needlessly slow by imposing constraints. Anecdotally, AMP sites always load a bit slower for me. The page will sit blank for a few seconds before finally dumping all of the content at once, as opposed to loading text immediately while it takes a moment to load the rest of the content that has a higher file-size. Without AMP, I can start reading a page before it's done loading. With AMP, especially on a desktop, I'm often stuck staring at a white screen for 15-20 seconds before anything shows up. I often find myself trying to cut the "amp" bit out of the URL to see if I can get to the original page. It's frustrating, and it is a big part of why I'm considering dumping Google as a search engine. That's just my experience, though - YMMV.
- ayoisaiah 8y ago
  AMP on the desktop? Don't think I've seen that before. I've only seen AMP links on mobile and I don't think it's returned in desktop search results

aceon48 8y ago

Lol this guy's site took over 10 seconds to load on my mobile. Invalidates anything he had to say

rchaud 8y ago
Ever heard of the HN "hug of death"? Sites load slower if there are a high number of concurrent connections at the time you're trying to visit.

fipple 8y ago

The headline is analogous to “Antitrust laws are not needed to prevent price fixing.” Treated as a statement of fact, it’s technically true, but it’s really a statement of policy opinion, whose weaknesses are clear.

liuyanghejerry 8y ago

The article is with prejudice somehow. You still need lots of apps which working perfectly with offline mode. For example reading books you already downloaded, watching movies you already downloaded, or whatever immutable content you already have. The author choose to making examples with apps that demands communications with outside world instantly, which makes the whole point weak.

gambler 8y ago

Google is steadily undermining the foundational principles of the web that made the platform so popular and allowed Google to do searching in the first place. The scary part is that they don't just offer an "alternative" technology like ActiveX, Flash, Applets, Silverlight and so on. They are influencing core web standards.

codedokode 8y ago

I tried to look at an example AMP page here [1]. When loading with an empty cache, it loads 5.5 Mb of files. I don't see where are the optimizations. It uses a custom font. Custom fonts are absolutely unnesessary for a news page; they only delay the moment when text becomes visible. Standard Windows fonts are of a good quality and don't need a replacement (which often renders very poorly on Windows XP). It uses a lot of scripts. Script block some browsers while parsing and executing. It has SVG images embedded into the page. If you want the page to load faster, you should move images into external files. AMP is directly linked to Google and cannot be used without it. Please look at the requirements for AMP HTML documents: [2] > AMP HTML documents MUST ... contain a <script async src="https://cdn.ampproject.org/v0.js"></script> https://cdn.ampproject.org/v0.js"></script> tag inside their head tag. So every AMP document MUST load a Google-controlled script. And by the way, it contains 12 000 lines when beautified. It contains different Google URLs like 'https://ampcid.google.com/v1/publisher:getClientId?key=' https://ampcid.google.com/v1/publisher:getClientId?key=' or 'https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKtqGxnoeIqVM33Uf7hRSa3GJxuzR7mLc' https://ampcid.google.com/v1/cache:getClientId?key=AIzaSyDKt... , references to Doubleclick and AdSense (but not other ad networks). Does every site need it? It contains a lot of code not necessary for most websites. For example, a XHR interceptor for "some trusted AMP viewers" [3] is included into the script. Or a cryptographic library for calculating sha hashes [4]. You can use only JS components approved by Google; the spec says: > Extended components > The script URL must start with https://cdn.ampproject.org https://cdn.ampproject.org So for example, Google might make a custom component for Facebook but not for QQ or Mixi. Google defines what widget can appear on an AMP page. If you are an ad network, you have to make negotiations with Google to be added (you have to negotiate with your competitor). If US government imposes sanctions on some foreign site, Google will have to comply. It is clearly a technology made for integrating news articles into a Google page (and judging by limitations in the spec, Google might plan to make a non-vebview native renderer for AMP pages). Don't believe when they try to pretend that it can be used independently as a standard or made for accelerating the web. [1] https://amp.theguardian.com/us-news/commentisfree/2016/feb/16/thomas-piketty-bernie-sanders-us-election-2016 https://amp.theguardian.com/us-news/commentisfree/2016/feb/1... [2] https://www.ampproject.org/docs/fundamentals/spec https://www.ampproject.org/docs/fundamentals/spec [3] https://github.com/ampproject/amphtml/issues/11294 https://github.com/ampproject/amphtml/issues/11294 [4] https://github.com/ampproject/amphtml/blob/master/src/service/crypto-impl.js https://github.com/ampproject/amphtml/blob/master/src/servic...