A new approach to web performance
ampproject.org
A new approach to web performance
1–10 of 177 posts
Re: A new approach to web performance
#2What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation.
If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads).
Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...
Re: A new approach to web performance
#3Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user.
These are systems where the read/write ratios are often 1000:1.
Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated the symptoms by introducing caching servers and horizontal scaling.
In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is "free" for the publisher.
I don't understand how any "Engineer" can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.
Re: A new approach to web performance
#4What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation. If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads). Here's an AMP page: https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...
Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article.
The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers that getting rid of all the bells and whistles will actually benefit them – and that if they don't do it, it will harm them because huge traffic drivers like Twitter won't put up with it anymore.
Re: A new approach to web performance
#5"With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts."
Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could adhere to so that their scripts behaved nicely.
Re: A new approach to web performance
#6Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
[deleted]
Re: A new approach to web performance
#7Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for each particular changed page.
About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…
Re: A new approach to web performance
#8Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html.
The question is this: what kind of overhead is a template rendering task (in js) for a modern browser, compared to the task of layout and rendering a finished html page? It will depend of course on the complexity of the data and the resulting page, as well as the browser, templating engine etc. I have no clue whether it's 1%, 10% or 50%.
Re: A new approach to web performance
#9Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for…
You can do that async - have the edit experience use the db then a publish action which re-generated the site.
As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
Re: A new approach to web performance
#10Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user. These are systems where the read/write ratios are often 1000:1. Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated…
It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html. The question is this: what kind of overhead is a template rendering task (in js) for a mod…
The slowdown caused by JS isn’t due as much to the rendering speed as the HTTP requests.