<story><title>A new approach to web performance</title><url>https://www.ampproject.org/how-it-works/</url></story><parent_chain><item><author>radicalbyte</author><text>Maybe it&amp;#x27;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.&lt;p&gt;These are systems where the read&amp;#x2F;write ratios are often 1000:1.&lt;p&gt;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.&lt;p&gt;In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is &amp;quot;free&amp;quot; for the publisher.&lt;p&gt;I don&amp;#x27;t understand how any &amp;quot;Engineer&amp;quot; can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.</text></item></parent_chain><comment><author>alkonaut</author><text>It&amp;#x27;s easy to forget that html isn&amp;#x27;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&amp;#x27;t &amp;quot;free&amp;quot; for the client just because it&amp;#x27;s html.&lt;p&gt;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&amp;#x27;s 1%, 10% or 50%.</text></comment>
<story><title>A new approach to web performance</title><url>https://www.ampproject.org/how-it-works/</url></story><parent_chain><item><author>radicalbyte</author><text>Maybe it&amp;#x27;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.&lt;p&gt;These are systems where the read&amp;#x2F;write ratios are often 1000:1.&lt;p&gt;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.&lt;p&gt;In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is &amp;quot;free&amp;quot; for the publisher.&lt;p&gt;I don&amp;#x27;t understand how any &amp;quot;Engineer&amp;quot; can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.</text></item></parent_chain><comment><author>mpweiher</author><text>Excellent point, I never understood that either, with developers being happy that their supercomputing buzzsaw can generate a couple of 100K of text in about a second.&lt;p&gt;OTOH...it turns out that so-called &amp;quot;static&amp;quot; content actually also requires quite a bit of processing.  Apache (or whichever server you are using) is not exactly doing nothing.  And it also turns out that this sort of processing is I&amp;#x2F;O heavy, which isn&amp;#x27;t exactly the fastest path on the machine, even if all the caching done by various entities (more processing) tries and mostly succeeds in making sure very little I&amp;#x2F;O actually takes place.&lt;p&gt;Add to that that moving data around nowadays is generally much more expensive than doing computation on it (several instructions per clock-cyle, multi-Gigahertz clocks, so well over a hundred clocks per main memory access, and millions per I&amp;#x2F;O, even with an SSD).&lt;p&gt;In short:  if we re-examine our assumptions in light of a changing environment, might a well-optimized &amp;quot;dynamic&amp;quot; stack not be faster than a &amp;quot;static&amp;quot; one?  (Compare:  VoltDB...).  And of course you could then cache the results in memory as well.</text></comment>