91–100 of 167 posts
Earlier quoted context omitted.
IMO we should introduce locale-dependent number formatting to HTML.
Excel has it and it's a complete nightmare. Never know in advance what's the locale of the document and the excel.
Without preloading, AMP is slower than the non-AMP version of the same webpage with a simple script blocker. And usually causing more traffic too.
I hope Google refrains from bullying website owners into making the internet a worse experience for people without 1GB+ data plan.
So basically Google could get 90% of what AMP provides without AMP itself, because the magic is in the caching and forcibly reducing the ad junk the page loads. Does that about sum it up?
Which is made clear in the AMP documentation itself. The AMP project isn't pretending they're bringing something unprecedented to the web... they're very open about the fact that most of the things you need to do to make your site "AMP compatible" are just speed-conscious best-practices (like only using CSS transitions that have hardware acceleration, or async loading of assets).
"The project enables the creation of websites and ads that are consistently fast, beautiful and high-performing across devices and distribution platforms."
"Web pages and ads published in the AMP open-source format load near instantly, giving users a smooth, more engaging experience on mobile and desktop."
That's directly from the AMP's project site. Those statements are half-truths at best.
Earlier quoted context omitted.
There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser. (Both are about advertising.)
> There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser You have evidence of these two claims or you're speculating?
I think the point of AMP is it gives Google a simple and reliable way to detect fast rendering pages that render well on mobile in a way that can't be easily gamed. When you allow unrestricted usage of JavaScript that's changing page content, loading styles etc. for example, detecting pages like this is more difficult. You can write performant pages without AMP but how would Google reliably detect pages like this? I'…
Google already has the tools to detect fast rendering pages, though they've more or less stopped talking about them after the introduction of AMP.
Answer: not as fast as the D lang forums. https://forum.dlang.org/
1. Plain, small html - page size is 6.1 kb (request took 700ms for me, I guess the server side rendering is pretty fast too), css file 11kb; note html, css and js are all properly minified
2. Font-awesome and jquery at the bottom of page to not block page rendering, both loaded throught cdn (although a fallback jQuery exists)
3. Site's own js is only 5.6k
4. No large static assets, only image on page is an svg dlogo
5. Did not check with js off, but saw hints of decent fallbacks for no-script
Earlier quoted context omitted.
> There are employees there who probably buy the idea that it's motivated by speed, but the project wasn't created primarily for speed, just like Chrome wasn't primarily motivated by the need to make a better browser You have evidence of these two claims or you're speculating?
AMP tech leads especially. For a quick glimpse you can read this: https://amphtml.wordpress.com/2018/03/08/standardizing-lesso...
> We started working on AMP because we were seeing the mobile web feel clunky and slow, falling behind the tightly-integrated, highly-optimized user experiences that walled garden platforms can offer. Yet we also knew there wasn’t a fundamental technology problem: you could build great experiences on the web with the right knowledge, resources, and management support. Thus we set out to create a framework that would provide a well-lit path to building great web-based experiences: AMP would be well documented, easily deployable, validatable, and opinionated about user-first principles.
So basically Google could get 90% of what AMP provides without AMP itself, because the magic is in the caching and forcibly reducing the ad junk the page loads. Does that about sum it up?
Yes, except how do you propose to implement caching and stripping out the ad junk without AMP?
AMP solves a very real problem, which is that our web stack is open to enormous abuse because it is sometimes too powerful for its own good. While we could make simple HTML that is as fast (of course we can), the reality is that we don't, and many don't often for tragedy of the commons reasons. And the counter-argument that search rankings should just favor this -- e.g. just promote speedy pages -- ignores that abuse would be absolutely rampant (and the other argument -- just run a layer of ad blockers -- completely misses the point). AMP isn't just an ideal, it's a strict set of enforced restrictions.
In previous discussions I've noted that we need an HTML lite to counter AMP, not just the same head-in-the-sand strawmen about how it serves no purpose. An HTML lite that is a mode in the browser, enforced on the DOM and JavaScript. The anti-AMP rhetoric makes it impossible to discuss rationally.
Answer: not as fast as the D lang forums. https://forum.dlang.org/
Holy crap. The internet on a phone can feel like this?!
Aside from making pages with few database queries, it's about removing all 3rd party dependencies and going same-origin to speed up the front-end too.
The 2 biggest things that slow me down are auth and analytics, but on the latter I trust you use an adblocker, and for auth I have a plan.
Earlier quoted context omitted.
Benchmarking is just logging the time taken during the process of waiting for the content to load, which is already happening to index the page. No special framework necessary. They aren't doing it because AMP gives far more data and keeps first party cookies because of the cached domain.
> Benchmarking is just logging the time taken during the process of waiting for the content to load I don't think it's as simple as you make out at all. Compared to just downloading the HTML and checking its contents, this requires executing JavaScript and rendering content in an actual browser which is orders of magnitude slower and more resource intensive.