1. A direct comparison to Facebook's react Github page may not be fair. Their page is 10 times heavier than the blog page - of course its going to be faster.
2. Actually the Facebook's React page is not that well designed when it comes to performance. I see a lot of scripts included in the FB react page blocking rendering (codemirror.js, etc) even in pages where they are not used. If those are removed, the time to first render should drop down by a lot.
3. I feel a more apt comparison would have be comparing to a purely static page like a blog hosted on Github. Not a page which actually includes a live code editor!
4. No one says the page loads in the DOMContentLoaded time. It is mostly a useless metric when it comes to performance measurement.
For reference, we haven't spent any time trying to optimize the react website for perf. Also that front page really needs to be rethought, we haven't updated it since launch...
I'll add: the React site uses the (larger and slower) development build of React because it can be useful to people visiting the site. Ordinarily you would use the prod build. Not to mention the lack of script bundling and inefficient (blocking) loading. Just hasn't been a priority for us.
I randomly picked the React website as an example github-hosted page to compare with (it was one of the first google results for github-hosted pages). I definitely didn't mean to pick on you all in particular! I'm not suggesting you should have spent a bunch of dev time making the landing page for a developer tool really fast on mobile devices (and React is a great tool!).
I updated my README file to compare page load speed with the Jekyll homepage too since it's a closer analog. But comparing to a random page that wasn't too optimized was sort of the point - most of the time, speed isn't the priority and that can make a big real-world difference for mobile users.
> For reference, we haven't spent any time trying to optimize the react website for perf.
That's probably true of every slow site on the web. Part of the purpose of AMP is that it forces your site to be fast. Of course you can optimize a regular HTML page and make it faster, but you can't pass AMP validation with a slow site.
> 1. A direct comparison to Facebook's react Github page may not be fair. Their page is 10 times heavier than the blog page - of course its going to be faster.
Isn't the point of AMP not to develop heavy sites for static content?
Sure, but the React homepage isn't static content... it has a code editor on it so that you can try out React right there on the page. That seems like a perfectly reasonable thing to want on the homepage of a JS library.
This is a great example of a modern looking website, that actually performs in a way one would expect from today's computers and browser optimizations. Instead it seems to be more important for developers to use the coolest new technology, even though it actually hurts the end-users.
React is all the hype right now. And it is a nice system for creating dynamic single page apps. But there is little reason to use it for static websites, which could be cached easily, instead of rerendering the website on the client with Javascript. And instead of having automatically cached static website, we use local storage and such to get something resembling a cache.
I would love to see some mechanical sympathy in modern web development, instead of cargo culting all the new tech.
You can use React to render static websites. You get the nice component model and the speed of static content. You can take a look at the react native[1][2] website for an example.
We've got our entire marketing site statically rendered. Looking forward to react 15, should get rid of lots of "data-reactid"s which should shave a bit off of the size of the rendered html.
You can actually do that at the moment with ReactDOMServer.renderToStaticMarkup(), which doesn't create any react-ids (but can't be used later by React on the client)
There's also such a thing as cargo cult criticism... when dismissing stuff as "hypes" and "trends" without really grasping the reasons behind the enthusiasm... for example, how one of the big advantages of React is that it can render on the server in a very convenient way.
True. I shouldn't have been that dismissive about React. My comment was really related to the explosion in popularity of client side rendered static websites. And React happens to be one of the more popular ways to implement them.
Well in this case the coolest new technology seems to be AMP, the use case for which is not so plain to anyone who knows how to make a modern looking website that actually performs in a way one would expect from today's computers and browser optimizations.
Mechanical sympathy implies that you tailor for very specific use cases.
For example my blog: Most visitors read a single article and leave. Optimization: Serve page as one big blob if possible. Inline the CSS. Avoid images and widgets. Social buttons are implemented as CSS-styled links without Javascript-iframe-img stuff.
Is there a reason you can't just build the site properly in the first place to load fast? AMP is an unnecessary step in doing so. It's nothing special. All AMP is, is a decided-upon set of restrictions for what you can do on a page. If you follow those same restrictions with normal HTML/CSS you can achieve the same results.
I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization.
Good developers can make fast sites (though that's not a given!!), but product managers will absolutely bloat your site.
"Add this third tracking/analytics tool";
"Add this custom ad format here";
"Oh this partner will give us tons of money if we put this widget on the page";
"Oh let's use Brightcove video player";
"Oh let's auto-play videos"; "drive-by A/B testing";
"We don't control this third-party 2MB image",
"The widget streams a 23MB .WAV file for background music that only auto-plays in mobile";
"Why build this in-house when we can just use this good third-party library?";
"Good third-party library costs too much, let's use this horrible but much cheaper one instead"; etc.
AMP allows you to tell your product manager: "Sorry! Not supported." Of course, with enough responses like this, a decision eventually comes down to not use AMP.
> AMP allows you to tell your product manager: "Sorry! Not supported."
I like this reason. It's both a good reason for AMP to exist (albeit to solve a sad problem, with the product managers), as well as to justify not using it myself :-)
> Of course, with enough responses like this, a decision eventually comes down to not use AMP.
Perhaps. But having an external set of guidelines that relate to an all-or-nothing benefit (inclusion in Google's AMP program) seems helpful to me (from the eye of a developer who cares about bloat).
A small team of good developers could also formulate their own set of guidelines in order to avoid bloat and achieve fast loading. But those guidelines will have to be guarded by the developers against "political" forces, and there's a distinct possibility that more and more compromises will be made.
Exclusion from the AMP program provides a line in the sand, so to say.
"All AMP is, is a decided-upon set of restrictions for what you can do on a page".
You say that like it's a bad thing! But that's the entire point. Without a clear set of rules, almost no one makes fast pages in real life.
This is especially true when you are working in a company where a wide mix of people have competing objectives. The developers want a fast page, the designers want a pretty page, the PMs want conversion, the business folks want lots of ads, etc. It makes it nearly impossible to build something fast without clear rules.
Take a random article on the TheVerge.com as an example. I'm sure they have fantastic web developers who want the site to load quickly and they definitely know how to build beautiful pages. But check out their normal responsive page you get if you visit their site directly on your phone:
Using Chrome's "Regular 2G" throttling, that page takes 19.82s to hit DOMContentLoaded and an insane 1.3 minutes to hit Load. The total mobile page weighs 2.5mb!
Now check the AMP version of that same page. You can find it by looking for the 'link rel="amphtml"' tag in the header of the page:
Using the same Chrome throttling settings, it hits DOMContentLoaded in 802ms and Load in 33.33s. And even then, almost all of that time is spent loading fonts and (in this particular article, very poorly optimized) images.
To a mobile user, that is a way better experience - the difference between bouncing and reading. And the only difference was having "a decided-upon set of restrictions".
As a desktop user, that is a way better experience too, but because AMP seems to be mostly mobile-focused, we desktop users get the "normal" experience typically.
If the site was built from the beginning with performance in mind, we'd all benefit, no matter what we're using to view the site.
I get that it has more to do with business side of things vs. the development side of things. Lots of hands in the pot at these companies and webdevs are only one part of it.
You are correct, but beg the question: why are so many popular websites so slow even if they are essentially static content?
If putting a brand on a set of techniques plus offering CDN space and serp priority gets publishers to actually build fast websites, then I am all in favor of it.
I totally agree. I have been back and forth on using bootstrap with CDN verse just plain simple css. I did a test with bourbon.io this morning to make a simple page with the responsive navbar. The resulting css file was just 1 kb compressed. That is a huge improvement over these heavier frameworks.
A major con against AMP in my opinion is that it is something else to learn on top of everything.
> I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization.
I've never understood why toddlers need training wheels on their bikes? Why don't they just bike properly in the first place?
If your view is that web developers working for publishers are "toddlers" in their industry, then I suppose this comparison is apt.
I guess the only oversight I see in my original post is that most of the time, the webdevs aren't the ones with the final say anyway and maybe branding the restrictions will make it more palatable to publishers. It's just sad that we're at the point where it has to be done this way.
But it is telling that publishers are fine with being restricted by AMP, when they could have implemented those restrictions extremely easily on their own instead of having to be hand-held through the whole thing.
The other issue I have is that it's generally intended for mobile only. If the site was built for speed and efficiency from the ground up, it would be a fast experience everywhere
Of course this is in comparison with Medium blog posts which take 10's of seconds and scroll at 5 fps. Plain HTML with no CSS works for me, which is super fast if you get used to the plain style.
This is why web performance needs to be something you actively and seriously measure: if you have a solid low-latency connection, you may have a completely different experience from someone with a high latency or packet loss connection which really amplifies the delay for each resource. This is compounded by developers almost always having the sites they work on cached and upgrading their hardware much faster than average, so it's easy to forget how painful all of that code is for e.g. an Android user on an average network when you mostly use an iPhone 6S over LTE / fiber.
Here's Medium with a 10s load-time over a simulated cellular connection:
Yeah, I try to believe anything about web performance until I measure it, not because I think people are trying to be deceptive but just because it's so easy to waste time in the wrong place if you don't have solid data.
Not everyone that might be interested in reading a Medium post lives in a country blessed with lightning-fast internet infrastructure. A large percentage of the world's population accesses the internet only through a phone. Even in here in the U.S. where I live there are people who fall into both the aforementioned categories.
So what's the best practice when it comes to valid html? This seems like a cool technology but trying to validate the https://www.ampproject.org/ site, the w3c validator fails so bad it's not even able to list all errors. The example post does a bit better but is still pretty far from valid html5.
Is there a way to do it in a standardised way or should that even be desired? All browsers I've tried seem to render it fine and quickly (assuming js and the normal bells and whistles).
To be honest, that was my bad--I didn't bother checking it because I know it used to fail validation a month or so ago.
Looking at it now though
[console.warn]
https://www.ampproject.org/:22:42 The tag 'noscript > style : boilerplate - old variant' is deprecated - use 'noscript > style : boilerplate' instead. (see https://www.ampproject.org/docs/reference/spec.html#required-markup)
That 'warning' comes up as a whopping great big red error for my AMP pages that still have the old boilerplate. It seems AMP make an exception for their project site.
Not sure why you're being downvoted. WebKit actually implements the WHATWG HTML parsing algorithm [1], and so do Trident [2] and Gecko [3].
The W3C HTML 4 spec didn't waste a word on parsing and simply referred to SGML [4], which (for very good reasons) no relevant browser actually implemented. Obviously, browser developers did some crazy/remarkable things before the WHATWG came along, but a lot of credit for today's lenient HTML parsing certainly belongs with the WHATWG.
The article's discussion of AMP's limitations regarding images is somewhat inaccurate.
Firstly, the claim that images must be supplied with a known height and width is wrong. All you need to provide to AMP is the aspect ratio of the image.
You can give the width as "16" and the height as "9" and AMP will calculate exactly what size to display the image. It would use any exact measurements provided only to determine the aspect ratio. That's why this layout can be called 'responsive' at all.
Secondly, if you won't even know the aspect ratio of your images with any certainty, AMP doesn't give a damn about exact dimensions for background-images.
With background-size: cover, background-images are actually extremely effective for responsive web design as long as you're not supplying massive images.
You might think it's a problem because the background-images will not be lazyloaded , but technically they sort of will be, because AMP intercepts everything in your page and serves it via HTTP/2 from its CDN. You just can't link the lazyload up with JavaScript callback.
What you can do is estimate the time it will take to download the image and configure a CSS animation to fire after a certain amount of time using the animation-delay CSS property.
haha :) I didn't even realize :) I've been running NoScript (in addition to my usual bloat-blockers uBlock and Ghostery) the past two weeks, to determine the trade-off between convenience and CPU/responsiveness on my low-end laptop (so far: so good!).
The crazy thing is that the demo-page actually loads quicker with NoScript on. Okay, so I didn't see the images (and because the text was Lorem Ipsum, I didn't realize they were missing), I'm on a high-bandwidth connection so unless the images are secretly huge, the images on their own shouldn't be too much of a factor to account for the difference.
So in other words, while AMP may be a useful line in the sand for responsive guidelines versus corporate politics / environment / product managers / etc, it's no replacement for just writing lean and efficient code in the first place (if at all possible).
edit: turns out the comparison wasn't entirely fair because obviously I didn't have Google's JS code cached. On the second load there's less of a difference.
AMP is not supposed to necessarily replace existing pages, but can rather be created by publishers as lightweight/performant alternatives for mobile visitors arriving via Google Search. Hence why you can declare
Slow sites are more than just HTML overload. Slow sites typically have additional HTTP requests (loading external CSS/JS files, AMP doesn't allow JS or external CSS files). They also load all images at once (AMP does lazy content loading). They don't cache as well as AMP does.
For companies, it's a framework that restricts the "bad" requirements that conflict with page loading performance.
Async just tries to load everything at once. If you're on mobile, you could have a slow connection. Trying to load an image at the bottom of the page at the same time as an image at the top of the page would compete for bandwidth. The idea behind lazy loading is that you give top priority to what needs to be downloaded right now.
You also don't bother loading what will never be seen, assuming the customer doesn't scroll down to the bottom of the site. This improves the customer's battery life because an HTTP request uses the radio which taxes the battery.
Further, by abiding by a set of standards, Google and others can trust the content will load quickly. That trust allows them to feature the content higher up in search results.
> Further, by abiding by a set of standards, Google and others can trust the content will load quickly. That trust allows them to feature the content higher up in search results.
So it is a Google closed club? "you use our library, your site ranks up"? I doubt this is true. If it is, I doubt it will endure. If it endures, I doubt I wish to live in this world.
> So it is a Google closed club? "you use our library, your site ranks up"?
Yes, unfortunately that is exactly the case.
Try a Google search for any news-related topic on a mobile device (at least in the US) and you'll see that only Google AMP pages are featured in the top scrollable news widget:
That's why most of the major publishers are providing AMP versions of their content. You can find the linked AMP version of any news article by checking the HTML source and looking for the "amp" link tag in the header.
Very cool. Might be nice for the example page to include real content--even a copy of the readme would suffice. But being able to click through various posts would give a better idea.
I am not able to reproduce the load times reported as benchmarks. My test runs on WebPageTest put start render and document complete at around the 700ms mark (Chrome 49 / no throttling):
The DOM Content loaded in this test is 157 ms. WPT uses a confusing terminology when it comes to this (Document complete time != Dom content loaded time)
True it is not the same as the 65ms claimed in the article but its not that far off too.
The location of the test matters too. The time to first byte in your test is 82 ms - so there is no way DOM complete can happen in 65 ms in your case :) Probably try different locations for your test..
Definitely not. Page load (thats the time the browser spinner stops spinning), first render, etc. are slightly better metrics.
But even page load time and first render times aren't without their own problems. Resources loaded asynchronously also count towards the page load time - however, they are not necessarily detrimental to the user experience. Similarly, some pages flash a white screen before contents actually starts to appear. In these cases, the first render also becomes meaningless since the user doesn't care about the "paint" of a white screen.
Mostly there is no one universal metric for all websites. Think about what your user wants to do on your site and optimise for that metric. For example, Twitter optimises for the time for the first tweet to appear on the timeline :)
Really nice idea and good boilerplate to start with.
It would be perfect as a starting point for a customer that want an AMP blog and probably in the near future it will be required.
I don't think we need ideas, just someone to put in the hour or two to optimize the React site. I'm confident we could cut down the load time immensely without much work. :)
Maybe support for Webmention[1] would be a nice addition? Medium is sort of a community after all and I think an alternative should have technology for talking to other sites. There's https://webmention.io/ and https://indiewebcamp.com/Jekmentions
1. A direct comparison to Facebook's react Github page may not be fair. Their page is 10 times heavier than the blog page - of course its going to be faster.
2. Actually the Facebook's React page is not that well designed when it comes to performance. I see a lot of scripts included in the FB react page blocking rendering (codemirror.js, etc) even in pages where they are not used. If those are removed, the time to first render should drop down by a lot.
3. I feel a more apt comparison would have be comparing to a purely static page like a blog hosted on Github. Not a page which actually includes a live code editor!
4. No one says the page loads in the DOMContentLoaded time. It is mostly a useless metric when it comes to performance measurement.