Google AMP lowered our page speed, and there's no choice but to use it
unlikekinds.com
unlikekinds.com
No, AMP pages can't be proven safe, because with AMP you can include ads which are a very common vector of malware.(if I understand your comment)
Also, I don't think you understood my comment. I mean safe as in not deanonymizing the user to pages they don't visit. If you preload a non-AMP page, you have deanonymized your user to a third party publisher and the ad servers on that page.
That does not make a big difference.
> Also, I don't think you understood my comment. I mean safe as in not deanonymizing the user to pages they don't visit. If you preload a non-AMP page, you have deanonymized your user to a third party publisher and the ad servers on that page.
Sorry I still don't get it, with AMP it's exactly the same except that 3rd party is the Google AMP server. You can also load analytics & trackers with AMP as well. There's no privacy in the AMP design goals.
This is not true for AMP analytics because Google define the JS and can defer sending analytics events until after the user has clicked on an item in the carousel.
Google can either preload content, allow non-AMP pages, protect users from data leakage, but not all three at once. They have chosen to sacrifice non-AMP content.
There's nothing you can do with the carousels that they can't do by just parsing the content or meta tags they could have defined. And when you click on the carousel, it could have redirected to their page.
And before you talk about the "speed" of preloading like I've seen this argument over and over again on AMP threads, AMP could have defined an HTTP header which would have made the browser understand it's an AMP page and load the cached AMP JS (among other stuff like refusing to load non-AMP content), there's no technical need for an AMP server.
This isn't how static analysis works. Yes, the halting problem says you can't determine safety of any possible input in a Turing-complete language, and yes, JS is Turing-complete. But it doesn't say you can't determine safety of some inputs. You can write an algorithm that outputs "Yes," "No," and "I don't know" just fine. Google can, if they desire, specify some rules / annotations that would help its analyzer answer "Yes" to more pages. They've chosen not to do that, and instead to only build an analyzer for AMP.
Besides, preloading pages is about fetching content, not rendering them, I think.
Isn't that exactly what AMP is? Whatever "rules" Google specifies will in fact, define a DSL/subset of HTML that can efficiently answer "yes". As people demand more and more capability in this ruleset, eventually you'll end up with something like AMP, only the syntax will be slightly different, but the fact that it is a weird subset of HTML will remain.
It’s possible to create a non-bloated fast news website. Neither publishers nor Google are interested in that.
See previous comment about the way the online news business works.
Yes, this is the solution and should be the ultimate goal to fight for. Those "staples" are precisely what's ruining the web journalism, and the Internet at large.
The AMP team will tell you that they are concerned with making the web faster, and it's the _search_ team that controls the carousel. Which is all well and good, but I can tell you that the _only_ reason any publisher is doing AMP is because they want the placement in the carousel and better search results.
As far as I can tell, google has no intention of ever allowing non-amp content they can't re-serve from their cache and add whatever analytics and tracking they want to from being ranked highly. AMP is a tactic to let them track the most lucrative mobile web users and take control away from publishers of original content.
Give it another fifty years and the web will finish civilizing.
I see you have not been following the CO2 news.
In fact, the absense of laws just means that some random individual can and will have power over you without you having any say on the matter.
From many different angles, AMP getting preferential treatment is heavy handed and clumsy, manipulative and forcing technology standards on the web that no one agreed on.
However, since Google aggressively preloads most of that data while you search, it gives you the illusion of AMP pages being lightweight.
Non-AMP pages? Oh, Google will happily penalize them even if they perform better.
USA Today (582KB, first item in the top news section) https://www.google.com/amp/s/amp.usatoday.com/amp/3431466002
Vox (486KB) https://www.google.com/amp/s/www.vox.com/platform/amp/policy...
The New Yorker (565KB) https://www.google.com/amp/s/www.newyorker.com/news/current/...
I meam, why exactly are 500kb of cruft is being served to present 5kb worth of data?
So even if the AMP Pages are small, they're still much larger than the page ought to be
---
USA Today AMP page: 45 requests. 755 KB transferred. 1.6 MB resource
USA Today EU Experience: 10 requests. 209 KB transferred. 251 KB resources.
AMP version is significantly worse for essentially the same content (AMP version and EU version are nearly identical)
---
VOX AMP: 37 requests. 575 KB transferred. 1.4 MB resources.
VOX AMP not served from Google [1]: 22 requests. 403 KB transferred. 935 KB resources.
VOX non-AMP [2]: 19 requests. 627 KB transferred. 1.3 MB resources
So, AMP is worse when served from Google. And on par with non-AMP version
---
The New Yorker AMP: 129 requests (and they keep coming). 796 KB transferred. 1.9 MB resources
The New Yorker AMP not served from Google [3]: 70 requests (and they keep coming). 745 KB transferred. 1.5 MB resources
The New Yorker non-AMP page[4]: 245 requests (and they keep coming). 8.2 MB transferred. 13 MB resources.
So. The only example where the AMP page is significantly better than the non-AMP pages.
---
But the page weight is already accounted for in Google Search algorithms, and The New Yorker page should have been deprioritised from search. It's not, it's in the carousel, it will redirect to the 13MB version on desktop. Meanwhile, as Vox, and USA Today and many many many others show, the regular properly made website will not differ significantly from AMP versions.
[1] https://www.vox.com/platform/amp/policy-and-politics/2019/4/...
[2] https://www.vox.com/policy-and-politics/2019/4/10/18305175/t...
[3] https://www.newyorker.com/news/current/william-barr-goes-ful...
[4] https://www.newyorker.com/news/current/william-barr-goes-ful...
Google decided to dominate the search world, and it now underpins a huge portion of online businesses. That comes with a level of responsibility to be fair to it's patrons that in this particular instance I feel isn't being met.
Of course they can do whatever they want, it is their product, but we don't have to like it.
That sure doesn't seem to be true at all.
See HTTPS adoption.
https://storage.googleapis.com/cdn.thenewstack.io/media/2018...
Great example. You just proved my point that it is possible to have positive change in large communities.
That graph shows that there's an obnoxiously large number of websites that don't support something that there's zero reason not to support.
It costs $0 and takes maybe half an hour to implement, browsers are screaming "not secure" to each visitor, and one in five websites still don't support it. "Make websites faster", on top of being vague, is way more difficult to implement.
If fast site performance ensures you get listed first, every site would get faster overnight.
And no attempt to fix the slowness of the modern web will succeed without blocking ads and tracking scripts.
This is the downside of the dominant browser being made by and ads-and-tracking company.
Apart from that a lot of websites started showing an overlay on top of the AMP pages, clicking on AMP pages don't work as expected a lot of times, it has a noticeable delay between actions (scrolling/tapping).
I disliked AMP when I first started seeing it but the way it has evolved has made the experience way worse than it started with... Probably because Google also caved in and tried to cater to customisations requests from big publishers.
The first solution is not AMP. The first solution is to go back to when a web page was a "page", not a program made up of cobbled together bits of JavaScript.
Cookie preference popups, join the newsletter popups, animated or dynamic ads, and everything else stupid websites do that causes the browser's rendering engine to grind away non-stop...
The current user experience is worse than I think it ever was.
But as other posters have comments, AMP is probably intended to be a control and data tracking system first, with user experience being second or lower priority.
You can't help the network request if it has to be made when the user clicks but there is nothing stopping browsers from preloading my site and nothing stopping google from noting that my site could be preloaded when it crawls it. Limiting ranking influence to sites with the AMP structure is an option Google has decided to make and not an inherent restriction in the technologies at play.
The technology behind AMP is very cool mind you, I just find it being an exclusive ranking factor to be an unecessary pressure to use their technology when many other technologies could work just as well. Google is a major force in the way people make websites and they are being very heavy handed in this instance.
There's a whole host of security problems with trying to see if an arbitrary site can be preloaded. Logging, tracking, etc, not to mention more nefarious tricks like mining Bitcoin in the background.
Maybe Google could try to detect those things, but then you just end up in a cat and mouse game. A "safe" subset of html and js that can't do those bad things is much, much easier to analyze. One such subset is AMP.
(Disclosure: I work at Google on Ads, and I work with the AMP folks a bunch. Speaking for myself, not the company.)
I'll grant you that the branding/communication here is atrocious, but as I'm reading this, what I'm seeing is "They should have implemented <description of AMP>, instead they implemented AMP, which is much worse."
AMP supports a subset of standard HTML, plus a whole bunch of AMP-specific extensions. That's a significantly different thing from being just a safe subset of HTML.
Webcomponent custom elements are part of the HTML5 standard.
`<literally-any-element-name-i-want-here>` is a valid subset of html. You added the "standard" modifier, which like, I mean, WebComponents are part of the standard, so using them is still a subset of standard HTML.
If you mean "they should have limited themselves to using older HTML APIs and doing custom polyfills based on css-classes instead of element names", which is probably closer to what you actually mean, I'd ask why.
The behavior would, in general, still be the same. You'd be required to include some metadata information, you'd be restricted to some amp.js provided to you, and you'd need to use class='amp-html' instead of <amp-html>. And that would be the entire difference.
Wow, color me disabused of the notion that AMP added stuff on top of that simple requirement to allow capture of publishers by Google, I had assumed bad intent and invented fanciful scenarios of what I would do if I were an evil corporation trying to control the web like requiring people to load my script on their pages and only using my analytics library so I would have all that data for me, or maybe just create a 'standard' set of components that I control and have people use those so they have tied up money in implementing my tech and I have lock in and in order to keep their ranking in my search app they sink more and more money into doing things the way I want, increasing my capture of them.
All sorts of evil stuff I might do, but gee, it turns out all Google did was publish a document saying use this stuff that is already standardized, and leave out these parts of the standards because they can be problematic and make things perform badly, and we will rank you higher in search results. Nothing else, just rank you higher.
Now I'm really sorry I thought Google was as evil as I am likely to be when working in a group of people trying to control a market. Google is as pure as the driven - gee, I don't know what, Snow? No, Climate Change means that metaphor is soon no more, what else can be driven, hmm, oh I know, a sociopath! Google is as pure as the driven sociopath, that sounds good.
Yes. Or at least, in practice its not really distinguishable from this other than technical nits that aren't practically relevant to the overall design or what anyone complains about.
>requiring people to load my script on their pages and only using my analytics library so I would have all that data for me, or maybe just create a 'standard' set of components that I control and have people use those so they have tied up money in implementing my tech and I have lock in and in order to keep their ranking in my search app they sink more and more money into doing things the way I want, increasing my capture of them.
These are the things you have to limit yourself to. You have to limit yourself to predetermined subsets of Javascript, because if not there's no way to ensure the safety/speed/etc. of the site.
You're shifting goalposts here. Now you want the set of things you're limited to using to be broader than is possible for valid technical reasons. You're also conflating AMP and Google, which like valid, because its confusing, but again, AMP doesn't require Google anything. So all of your complaints about forcing you to use Google's analytics library or include Google's JS aren't true. Yes, for AMP (JS) to work you need to include a Cache's JS, and Google is the biggest cache, but they aren't the only one.
As for the rest of your post:
> Don't be snarky. Comments should get more civil and substantive, not less, as a topic gets more divisive.
Could you at least try to be polite.
The first is they conclude they're going to get slapped no matter what and then do whatever they want and write off the penalties as unavoidable because better behavior doesn't actually avoid them anyway.
The second is they conclude that the only way to avoid the penalties is to grease the right palms, you induce them to figure out how to do that, and then they still do whatever they want because once you force them to corrupt your institutions in order to not be treated unfairly, those institutions no longer threaten them even when they misbehave.
The only scenario that leads to behavior improvements is the one where all the penalties are assigned justly and proportionally, to behavior that could reasonably be predicted ahead of time as prohibited.
None of the FAANG is being slapped by the EU for the wrong stuff. They aren't being slapped for your specific example (yet) but that doesn't mean that forcing their self-serving choices onto powerless users deserves a pass.
A lot of the other stuff is things like not putting links to another search engine's results page in their search engine's results page. It's pure nonsense.
European Commission fines are no small matter. They may be small at first, and may even be zero (just a warning), but the policy is to increase fines on non-compliance up to the point where the target complies. They can't write off penalties as unavoidable.
Once you convince a company that paying whatever it takes to buy a government is the only way to avoid random multi-billion dollar fines, you've created a long-term structural problem, because it becomes the status quo and is hard to undo. And then the government can't even punish them when they're actually being bad.
it's not about making the internet faster, it's about making it easy for google's stupid scroller.
Are you saying preloading content _doesn't_ make the internet faster?
AMP is search engine "paid placement" reborn.
The "payment" is letting Google serve the pages and do the user tracking.
I think for static articles 50kb should be plenty. The linked page itself uses only 35kb and a third of that is fontawesome. And 32kb of that is actually unused without javascript enabled. So the site only uses 3kb, but 50kb is absurdly small?
This site (Hacker News) gets by with 2 kb.
If you minified the css along with the html you could get it significantly smaller.
Also using individual css properties instead of combining them using the shorthand syntax, I assume any minifier would do that as well.
Of course it's probably really hard to do because some class names are en/dis-abled in javascript and the names have to stay.
However, since Google aggressively preloads most of that data while you search, it gives you the illusion of AMP pages being lightweight.
Non-AMP pages? Oh, Google will happily penalize them even if they perform better.
Normally a page could insert a link for a global CSS document, or have a document corresponding to each feature (video.css, audio.css). AMP doesn't allow this, you have to inline the styles into a single style block in the head of the document.
The only way to do this if you have a site with a long tail of features is to track which elements are rendered and then before flushing the page calculate which styles should be inlined.
AMP's approach is workable, but is at odds with how most sites and frameworks use CSS, and means the web framework and static resource build pipeline have to be redesigned around AMP constraints. And in the worse case, you'll discover than some content combinations happen to trip the 50k limit anyway, and silently fail.
I think you would be challenged to find a single page that needed that much; please give an example if you have one. Most single page articles I have tested use less than 5kb. codepen.com uses like 6 kb on load of a new pen. gmail.com completely loads with 5kb and doesn't load more.
> For example a news article might have a video player, audio player, image carousel, map, data tables, scroll away images, etc.
This is definitely a concern, but 50kb is high enough that you should be able to fit custom css for everything you mentioned. I think 10x what most single pages use is pretty reasonable, and certainly not "an absurdly small, arbitrary limit".
A significant portion of time is spent calculating styles from css so keeping it small is a real bonus to load times.
> AMP's approach is workable, but is at odds with how most sites and frameworks use CSS, and means the web framework and static resource build pipeline have to be redesigned around AMP constraints.
Pretty much every site I have looked at since my first comment besides Github loads less than 50kb (much of which is unused) anyway. If you are really hitting the 50kb limit, you probably need to redesign anyway for desktop so AMP should come mostly for free.
Just for grins and giggles, I occasionally charge my first gen iPod Touch from 2007. Most web pages are unusable - except for HN and daringfireball.
I have no affiliation with the site below. I just saw it on Show HN a few years ago.
The mobile UX here is non existent.
It doesn't have any specialist mobile UX, but it also doesn't have any need for specialized mobile UX. It has pretty nearly the best mobile discussion UX I've seen simply by not trying too hard.
It has clean UX for desktop. Which thankfully translates to mobile good enough because we built mobile concepts to deal with it (zooming).
But no, that doesn't mean it has mobile UX.
# Otherwise the ends of really long lines scroll off the side of your phone and
# you can't read them because your browser is a piece of junk.The problem is designers and their bosses/clients. They equate design with looks. As a result, they see design as solving the problem of aesthetic. They fail to realize this is a problem which very few people care about on the web. So long as it passes the smell test of credibility, no one cares. (Excluding a handful of cases.)
As a result, we, the users, must suffer.
I‘m an outlier on this site because I generally like redesigns and all that comes with modern web stuff (white space, rounded corners, flat, light drop shadow, generally clean and option for dark mode).
I find it‘s easy to test. Take a redesign you didn‘t think was necessary and then look at it 3 years later. Design changes over time. It‘s just life.
HN for some reason did age decently because it‘s very spartan and minimal. I like it. Even mobile is fine for reading. Not so much for contributing though.
Edit: Actually, everyday users might not care much either way. UNTIL some other site with similar functionality comes along but looks much more modern. Or if the site is trying to get new users.
Design is not about what one likes. It is about what helps one solve a problem.
Web designers and their bosses/clients reduce "design" to the creation of the look-and-feel of websites. For them, design is all about how something looks. This is something which is highly subjective.
The flaw in this is that it's not how users think. Users have a job-to-be-done. A good design is one that helps them accomplish that job. A better design is one that helps them accomplish that job better, faster, or easier. A bad design is one which doesn't help them or makes it worse.
Consider a monolingual English speaker using an ATM in China. You will never hear them say, "Well, I can't get my money because I don't understand Chinese. However, this ATM looks so nice I'm going to try to use it again."
It doesn't matter how great that ATM looks if the user cannot accomplish their task.
Yes, aesthetics have a place, but it's a very diminished place of importance. Aesthetics is much less important than most web designers and bosses/clients think.
It's time they get over themselves and start thinking about users.
I mean, early/mid 2000s design was still bad (especially when people learned about the gradient tool and drop shadow filter), but at least browsers were limited enough to mostly contain the damage.
This is pretty standard. You have to sign one to contribute to Emacs.
> Note, you don’t grant these rights to the AMP Project, you grant them to Google. Google owns the code and patents.
On the other hand, in AMP's case the CLA allows Google to start distributing the software under a proprietary license in the future, if they so desire.
One example of this difference was the time when Gitlab stopped requiring a CLA, after being prompted to do so by the Debian project: https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l...
Also, you get the added benefit of a browser whose maker has no interest in tracking your every move.
i don't think the AMP carousel is anything but a feature. people need to stop treating companies as services. products can go away in the blink of an eye.
except no, people say they are "forced" to use google amp. well duh, google was also "forced" to make amp due to the shitty way people design websites in general(slow, ads in awkward places leading people to install ad blockers etc etc)
amp is inevitable in my opinion - the old style of ads are intolerable to most users now and google needs to keep up since ads are their core business
that's how
This wasn't always so in the US and it's not the same philosophy in EU. However, it is a valid and consistent view.
Corollary 2: Human attention is considered equivalent to monetary value of exactly $0 by US government.
Corollary 3: You should never trust your government to be smart or do right thing for you.
In US, it's very safe to do this without violence but even in significantly less safe places, people have successfully done this peacefully [1] [2] [3]
[1] https://en.m.wikipedia.org/wiki/2013_Delhi_Legislative_Assem...
[2] https://en.m.wikipedia.org/wiki/2011_West_Bengal_Legislative...
[3] https://en.m.wikipedia.org/wiki/October_2005_Bihar_Legislati...
- Killing email with gmail specific garbage
- Killing mobile phones with walled gardens
- Killing browsers by implementing their own spec and fuck everybody else
- Killing open source tools by releasing closed source extensions for VS Code
Google has done a complete and total 180 in the past 10 years. I remember when the name inspired and made you feel safe that this thing you were using was made with character and thought to your well-being. Now it's a dry-heave feeling having to touch anything Google.
Was it there 10 years ago? I don’t think so. At least not so explicitly.
AdSubtract advertised it's ability to block doubleclick.com cookies in March of 2000: https://www.computerworld.com.au/article/91102/adsubtract_bl...
The article also mentions Siemens' WebWasher product which blocked cookies. Other cookie-blocking products were released in the same time period.
at that time Google was the good guy serving up only text ads.
In many respects the Internet doesn't route around damage so much as accumulate damage. And that's partly the result of apologists within the engineering community endlessly excusing Google (and more recently Mozilla), as well as increasingly greater numbers of engineers having no memory or even conception of running fundamental services independently. As the base layers become increasingly complex economies of scale increasingly prefer centralization, both in design and especially implementation.
There will always be competition. In many respects Cloudflare is a breath of fresh air, pushing against the stampede to AWS. Likewise, Mozilla viz-a-viz Chrome. But there are certain interests that large players will always share to the detriment of small organizations and individuals. DoH and DoT embedded in the browser intrinsically favor large organizations, and specifically Google and Cloudflare. And why do they promote DoH and DoT in the browser rather than promoting it at the system level (i.e. in Windows, Systemd, etc)? Because it's (a) less costly for them and (b) furthers their competitive commercial interests in their battle with other large organizations.
One reads endless apologia on HN about how people would rather send their DNS requests to Cloudflare and Google rather than their ISP, as if those were the only realistic options, and no matter that doing so doesn't require delegating even more functionality to the browser oligopoly. They've already given up. They see their own role as choosing sides as consumers rather than actively participating as producers of these technologies, which is so utterly depressing from the perspectives of preserving an open internet and promoting free software. (For example, web developers are fine with DoH because they don't see how it effects their own server-side and client-side development. It doesn't matter to them that it would make it increasingly difficult to independently implement and maintain the software and systems--they're just consumers. QUIC? Not their concern--that's the responsibility of nginx and node.js, no matter that those projects likely never could have been founded outside large corporations if they first had to climb the steep hill to HTTP/3 and QUIC.)
How do we stop this? By keeping an eye on long-term goals. While IPv6 and DNSSEC are more complex than some alternatives, from a long-term perspective they minimize overall complexity and substantially preserve independence, such as it is. Some options are even more clear cut: push DoH and DoT into the system resolver (and OpenBSD is doing, and projects like unbound and even, IIRC, systemd already support).
I'm not sure what you are getting at. IPv6 is pretty similar to IPv4 - and in some ways simpler - and I'm not aware of any other alternative. And I don't really see how DNSSEC (or IPv6) relates to anything else you are talking about - DoH addresses a different use case.
Local DNSSEC doesn't solve ISP confidentiality but it does prevent NXDOMAIN substitutions, which is one of the biggest immediate benefits for browser-based, default-enabled DoH/DoT. And one argument for doing DoH/DoT to centralized servers rather than locally is that it partly obviates the need for DNSSEC--it's "simpler" because it doesn't depend on orchestrating larger infrastructure changes. (I guess the logic is that without DNSSEC centralization is inevitable anyhow, and if people are convinced that ubiquitous DNSSEC will never come than doing DoH/DoT in the browser vs at the system resolver is a distinction without a difference. A poor argument but implicit nonetheless.)
[1] At work I suggested Cilium with IPv6 and IPsec for policy and LAN confidentiality of K8S clusters but everybody thought I was nuts and favored Cilium's UDP+IPv4+VXLAN mode and transparent Istio proxies for automagic mutual TLS. Why? Because it's what they know and understand and they can reasonably expect everybody else will make the same judgment. It's ultimately a much more complex, error prone, less performant, and less flexible approach but it's the path of least resistance. And in the long-term the complexity will mean proprietary managed solutions will prove that much more enticing, an irony apparently invisible to people who believe K8S will keep them independent of AWS, Azure, etc,
As I understand it, there you have basically 3 options for local DNS w/ DNSSEC - 1) you can run a local recursive resolver, such as BIND; 2) You can use a non-validating stub resolver which requires that you trust the the recursive resolver you use _and_ the channel to the resolver; or 3) You can use a validating stub resolver. The problem with option 3, is that I don't believe it's possible to do DNSSEC validation for a record without fetching a bunch of parent records - so you end up running something that looks a lot like a recursive resolver with a cache, so, its really not clear to me why someone would do this over option 1.
Anyway, that basically leaves you with two options: a recursive DNS server or you have to trust the recursive server that you do use and the channel to the server. While its fine to run your own recursive server if you want to, there are legit reasons someone (such as myself) wouldn't want to - its another service to manage and it may not perform as well as a shared cache in a recursive server someone else is maintaining. What that leaves me with, is that I want to use a non-validating stub resolver and I suspect that is true for most people as well.
Unfortunately, as DNS traffic is not encrypted, when I use a non-validating stub resolver, it's easy for anyone that can eaves drop on my traffic can log where I'm going. Anyone that can modify traffic, can send me whatever responses they want. It doesn't matter if the domain I request is protected by DNSSEC if someone in the middle sends me back a bogus response that my resolver has no way to verify.
DoH actually works alongside DNSSEC in some situations - by encrypting the channel between my stub resolver and a validating recursive resolver, it means that DNSSEC validation can't be easily stripped out by someone that controls whatever local network I'm connected to.
Even with a local validating recursive resolver, you have little protection against NXDOMAIN substitutions and the like unless the domain you are talking to has DNSSEC enabled. However, DNSSEC is being slowly deployed and, in my opinion, it's very unclear if it will ever get to 100%. Unless it does, something like DoH still has value in protecting users from interference on the local network for non-DNSSEC domains.
My points: I don't think that a Local DNSSEC resolver running on everyone's computer is realistic; DoH actually benefits DNSSEC by securing the channel between a stub resolver and a validating recursive resolver.
Sources:
2) DNSSEC isn't a panacea and there are absolutely problems with depending on it. And of course it doesn't directly address the confidentiality issue, either. My point is simply that too many technically-oriented people are willing to throw up their hands; they'll give centralized DoH/DoT to Google and Cloudflare a pass as a fait accompli but endlessly bikeshed the downsides to DNSSEC.
In truth DNS confidentiality is a fundamentally difficult problem because DNS is fundamentally centralized, as would be any system reliant on recognizable identifiers for its namespacing. And while we can maybe trust Cloudflare and Google today that can easily change, and there's no going back once we centralize even further--as described by another poster who described how 8.8.8.8 is ubiquitous enough at this point that it has set expectations for actual resolution behavior. It's not DoH or DoT that is the problem, per se, it's the fact that it will be enabled by default and be performed by the browser directly to Google and Cloudflare.
Authentication is solvable, however, and while more difficult to orchestrate DNSSEC usage, the result would be preferable long-term compared to making Google and Cloudflare yet another point of centralization. Even if you think DNSSEC sucks it represents at this very moment a stark choice between a whole universe of sucky options in the future versus vs the preservation of our ability to pursue better options down the road, independent of its specific merits. Would you prefer DNSCurve over DNSSEC? Once they broker most DNS traffic both Google and Cloudflare will have an even stronger incentive to promote the most baroque alternatives because additional complexity favors the large incumbents, just as large corporations, once regulation becomes inevitable, will lobby for particularly complex regulations requiring particularly costly compliance as a barrier to competition.
And, again, it doesn't require you to necessarily do anything. You don't need to be a mechanic to understand the value in preserving the viability of being a mechanic.
* We've tried having ISPs run recursive resolvers - and many ISPs demonstrated that they either ran slow servers, servers that sent back faked responses, or both.
* DNSSEC lets you validate a response, thus getting rid of faked responses. However, even if the OS making running a local DNSSEC validating resolver easy, I don't see how that can be made fast. In order to validate any response, it has to be validated up through the root, which requires more requests. Caching helps, but, it still won't be as fast as a well implemented shared cache.
* It seems like it would be possible a central cache to return all of the signatures up through the root in response to a request to allow for local verification. That would solve the extra requests issue while ensuring that all responses are genuine. So, even if an ISP wanted to send back bad responses, they couldn't. However, it's my understanding that there are real advantages to keeping DNS requests and responses to below ~1,280 bytes to fit inside of single transport frames - having to send all of that extra data seems like it would make it hard to do that. Since DNSSEC uses RSA keys, which are huge, that would probably be impossible, but even with EC keys, it might be tricky. Also, it doesn't really address the very real issue that some ISPs have done a poor job by running slow DNS servers.
* Any solution that doesn't involve some sort of centralized cache, is going to have a hard time keeping up with 8.8.8.8 or 1.1.1.1 performance wise.
So, while I value decentralized solutions, it just feels like it's a very difficult proposition for a decentralized solution to win when it's at a performance disadvantage.
I'm tired. I want to go make some changes that improve things. I expect I'll move to a forwarding configuration just so I can let people consider a "win" and move on something else.
Which I believe both can be publicly held, and as stated in Florida, shareholders can actually go after them for failing to create a public benefit.
Perhaps in the future, we should be hesitant to ascribe positive social traits to corporations which don't have this in-built motivation.
- Yeah, that gmail specific stuff is evil, except it isn't gmail specific at all.
- Yeah, killing browsers with Chrome. Just like IE6 except it's open source, cross-platform, evergreen, and pushes standards forward rather then trying to subvert them. The biggest problem now is others like MS using their browser engine is reducing diversity, but I guess that's their fault for making it open source. evil!
- And yeah, they have now officially destroyed VSCode (which includes lots of closed source MS stuff) by releasing a closed source extension.
For a lot of people, it is.
It shows what a silly contortion he was going through to tell us to hate Google.
You can hate and have valid arguments against AMP, but... on this article, in particular, where is the data?
How can people comment and form an opinion based on basically nothing?
Am I missing the "before and after" links with the benchmarks?
You can run the test yourself on the AMP and non-AMP versions of an identical article to see yourself.
(Note: sometimes the numbers are off the first couple of times you run tests. If you run them multiple times, the AMP articles tend to score (sometimes significantly) lower.)
Non-AMP: https://unlikekinds.com/article/google-amp-page-speed (Results: https://imgur.com/OVpdwyh)
AMP: https://unlikekinds.com/amp/article/google-amp-page-speed (Results: https://imgur.com/I3ha7Gi)
Edit: More data here: https://news.ycombinator.com/item?id=19630846
Non AMP version:https://www.dropbox.com/s/lclqqdbdliuofjf/Screenshot%202019-...
My email is on my profile if you want to talk about this. Maybe we can help.
Edit: If you compare against the cached version, the version that your mobile users are going to hit, the results are much much better: https://www.dropbox.com/s/c2y5akqclcim7tm/Screenshot%202019-...
But just now I ran it until I got bored of running it, alternating between amp/non-amp, chrome on Windows 10 (normally I'm Chromium on Fedora, but let's try mainstream)
AMP: 75 90 91 91 91 89 80 91 (avg 87.25)
Non-AMP: 95 95 96 96 95 94 96 (avg 95.29)
So I feel pretty confident about that. Also appears more consistent (and apparently faster than the amp cached one somehow - probably because it wasn't prefetched by Google)
The 'Email' field in the profile is not visible to other users. You should add it to the 'About' field.
I realise it isn't scientific but I think it's pretty clear
It’s trivial to make a site that’s more performant than AMP. But then Google gives exclusive preference to AMP by hosting it in its cache, preliading assets etc. And by penalizing your website.
non-amp: https://www.webpagetest.org/result/190411_1B_7c5b8e0d2f067ad...
amp: https://www.webpagetest.org/result/190411_RF_776066ee3b0226f...
Your site does pretty similarly with non-AMP and AMP. On the median of 9 runs PLT and fully loaded time are better on AMP, but speed index and time to interactive are better on non-AMP. Digging into it more, the time difference is completely due to how long it takes your site to serve HTML, and the biggest thing you could do to speed your site up would be making the server return the HTML sooner, perhaps by adding a cache.
Testing with curl, your site takes 880ms on average to serve non-AMP, but 1120ms to serve non-AMP. Graph: https://i.imgur.com/BlWqSoo.png
That's not an AMP thing, that's a your-serving-stack thing.
(Disclosure: I work at Google, and used to work on mod_pagespeed)
According to the webpagetest.org results you linked, which ran the test 9 times on each page, the mean time to first byte for the AMP page is 1005, and for non-AMP it's 989.
Which is just 16 ms.
But the time to visually complete for example on non-AMP is 1955, and on AMP it's 2166.
Which is a difference of 211 ms (which percentage wise is almost 10x bigger (I think, I'm not super mathy)
This implies to me that the problem is AMP not the server.
But if your data is correct then perhaps something is up.
The thing is, I know how the site is coded. The AMP version just excludes things almost exclusively. Although it does have to render the CSS in place (the fragment is cached) rather than just link to a stylesheet.
But here's the thing, even if that is the problem, the only reason it's like that is because that's what AMP requires.
Maybe there's changes we could make on the server, but according to this webpagetest site, the problem doesn't appear to be the server nearly as much as the rest of the render process.
for prefix in article amp/article; do
echo $(for i in {1..9} ; do
(time curl -sS https://unlikekinds.com/$prefix/google-amp-page-speed > \
/dev/null) 2>&1 | grep real | awk '{print $2}'
done)
done
I shouldn't have focused so much on the difference between the AMP and non-AMP times, though. The main thing I wanted to point out is that if your server is taking almost a second to return html there's a lot you could do to improve pageloads right there.
And thanks for sort of fact checking, for a second I thought whoa, that could be it, all on the server side.
Don't think it is though. I might set up some performance testing on a local copy to check the difference between the two just to be sure (especially because the article ended up getting a lot of attention.)
That's some pretty badass shell scripting, I'll give it a try in a bit.
I love technology and love to learn. When something isn't working as supposed, I want to learn why.
I provided links where it shows that all these claims are not actually true.
But if there is something wrong with my methodology, I want to learn about that as well!
How did all the work this company did add any value for someone using DuckDuckGo, Bing, Ecosia, etc considering the site was already fast?
This type of activity is a bad outcome.
Same with Baidu. https://9to5google.com/2017/03/07/accelerated-mobile-pages-e...
Google IS the web.
https://www.theamericanconservative.com/articles/robert-bork...
Especially given Google's CDN and the fact it's likely to be preloaded in practice?
I find myself wondering if this isn't just some artifact of the Chrome tool being used to measure performance -- especially since that tool reports an overall score like "94", not an actual speed -- and the weightings it uses [1] could be different from what AMP is designed specifically to speed up. Also it would have to be measured across a wide variety of locations worldwide, etc., certainly if the author's webserver is in their own city, for example.
A lot more data, measured rigorously, would be needed to prove that AMP is actually slower in practice -- it's a bold claim.
[1] https://developers.google.com/web/tools/lighthouse/scoring
Edit, apparently it should be linked from here, as the title and url of the article has changed: http://unlikekinds.com/t/how-google-is-creating-the-one-page...
I'd happily choose the web over the other two alternatives. Sure it'd be great to have an open standard achieving the same thing as AMP, but it's 2019 and we haven't seen it yet.
Its hard enough getting a major publishing brand accepted by google as a news publisher.
(I had to look it up too)
Aside from that, Google News content is heavily integrated into the normal Google Search pages. It's not simply a matter of simply ignoring it; Google makes their Google News results some of the top results for searches for current events.
>... the position on Google’s results that can literally mean the difference between a failed business and one that makes millions of dollars
looks to me like your business is the tail, and here you are trying to wag the dog.
It makes sites take multiple minutes to display after they redirect to the original version.
Fun fact, blocking the amp JS makes amp pages artificially slow because they hide everything in css by default.
AMP as a solution to slow websites is like a chainsaw as a solution to an itchy foot.
AMP is just a set of conventions and limitations that, when followed, make for a fast site.
AMP is more than that. AMP is the CDN that allows Google.com to preload your web page, and sits as an intermediary between you and your users.
Also, AMP is not a CDN. A CDN is a component of an AMP preloading implementation.
If Google wanted to highlight fast/penalise slow sites, they could simply measure the load time of a site when they index it.
But that would only achieve their stated goals, it wouldn’t achieve their actual goals.
Google is hurtling toward an antitrust case they won’t win, and it will really be all their fault.
Also, if speed is their goal, why does the mandatory AMP 'boilerplate' include a CSS-driven 8 second delay before content is shown, that is removed if the client loads the AMP JS?
Oh right. I know the answer. It's to give the impression that blocking third-party resources (such as AMP JS) via e.g. a content blocker, won't make the site faster. Which as we know, is a load of shit.
You might have the best of intentions and donate your entire salary to homeless blind children - that doesn't mean for a second that I believe google's actual goals with AMP are anything less than exerting more control over the web for their own purposes.
You should stop and do some serious research on why people don't like AMP. You're talking about the Web like it's a Google "product." You're hijacking the Web in a way that will eventually destroy it.
Publishers don't want their content restricted and hosted on Google's servers on Google's domain, but they are getting their arms twisted by reduced rankings if they don't implement it. They also don't fully understand the long term implications of what they are doing.
I said "they could simply measure the load time of a site when they index it." Their indexer, running from their servers could be their "reference point" for this content.
Also position on the SERP page is a major indicator of relevancy. Biasing results because they use AMP is unfair and inaccurate.
But you can. Often it doesn't matter because you aren't a globally distributed cache, but if you are cloudflare[1] (or apparently Microsoft[2]), you can and do.
[1]: https://amp.cloudflare.com/
[2]: https://github.com/ampproject/amphtml/blob/master/caches.jso...
It's not just conventions and limitations.
For example, you can't use an img tag on an AMP page. That's invalid AMP. You have to use an amp-img tag, which is rendered client side with js.
Another example is with forms. It forces you to include the amp-form js.
If it were just best practise, I'd be far happier to go along with it. Kind of the point here is that we were already using best practise, because the site was super fast.
Google only uses this in an incredibly small way, yet I've seen SEO people at multiple companies hammering on it like it's some magical SEO juicer. It's not. Just don't be in the bottom 10% (Google uses a slice even smaller than 10%).
I like that Google wants the web to be faster, but if I could axe one product that causes a lot of angst, it's that damn pagespeed score.
Why would I need CSS for iPhone? I don't have an iPhone. Also I'm now browsing from my laptop, so I don't need mobile specific CSS either. Isn't there a way for the responsive site to load CSS specific to the device/display?
In theory on your own site you could use user agent sniffing to worn out what CSS to send, but it's still not a great idea because you'll be wrong at least some of the time.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Safari/605.1.15I think the adoption rate for UserAgentSpoofers, could be a related metric, approximating the value of "some of the time"
my user agent rotates randomly, or when the spoofer button is clicked
For few months now it seems to me that Sparkpost is a favorite choice of spammers. Perhaps its the low cost or maybe its because they never ever answered to a single spam@sparkpost.com email I send forwarding abusers content. None, zero nada! I can report someone... silence... an then 3 days new letter pops up from a new domain (but same IP) from Sparkpost.
That's why I need to be able to block whole IPs.
As far as I know, the 50KB limit is per page. I can't see why a typical single page should require that much CSS where the CSS included is actively used on that page. If you're going to include e.g. the CSS for every Bootstrap component on every page you're easily going to go over the limit but the whole point of the limit is to discourage you from doing that.
The OP article should only require a modest amount of CSS I think, same for most pages. People here hate on AMP a lot, but "avoid excessive CSS" is a good guideline in my opinion.