Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server.
Wow! Turns out I'm not the only one who was surprised by that statement. So he wrote a follow-up that explains "why client-side templating is wrong"; it provides more nuance than the original post:
Populating an HTML page with default data is a server-side job because there is no reason to do it on the client, and every reason for not doing it on the client. It is a needless performance hit that can easily be avoided by a server-side templating system such as JSP or ASP.
To me this could mean one of two things:
- Do not use client-side templating at all. Render all data server-side as HTML for the initial page view.
- Do not send an AJAX request back to the server after loading the shell of your app (a style that plagues GWT apps like AdWords and Twitter's old UI). Instead, you should provide the initial view data server-side in the first page HTML (i.e., as a JSON blob) and render it with JavaScript immediately after load.
Style #2 is what I see becoming more popular. For example, check out the source of Google Analytics. The first page load is a small HTML shell, JS and CSS resources, and a blob of JSON. Some may say that this style prevents you from getting indexed, but that's old information. Web crawlers now support running JavaScript, meaning you don't need to use 2009-era hacks like /#! anymore.
PPK resolves the ambiguity with this:
Then, when both framework and application are fully initialised, the user starts interacting with the site. By this time all initial costs have been incurred, so of course you use JavaScript here to show new data and change the interface. It would be wasteful not to, after all the work the browser has gone through.
So he definitely means option #1 from above: Never use JavaScript for first page load rendering. Now other detail from his post makes more sense (emphasis mine):
I think it is wasteful to have a framework parse the DOM and figure out which bits of default data to put where while it is also initialising itself and its data bindings. Essentially, the user can do nothing until the browser has gone through all these steps, and performance (and, even more importantly, perceived performance) suffers. The mobile processor may be idle 99% of the time, but populating a new web page with default data takes place exactly in the 1% of the time it is not idle. Better make the process as fast and painless as possible by not doing it in the browser at all.
I'd guess PPK would be okay with how ReactJS can render a template client- or server-side using the same code. With React the first page load can be dumb HTML that's later decorated by JavaScript to come alive for user interaction. So I think PPK's concern isn't about JavaScript templating. The debate is whether JavaScript should be required to run before a page is first rendered (a requirement of style #2 above).
Instead of more words about philosophy and architecture, I decided to understand this with numbers by putting it to the test on real hardware. What follows is the experiment I ran.
Experiment HTML pages
I wrote a small server in Go that generates test pages that I figure are a fair approximation of "templating complexity". The silly example I used is straight out of the HTML5 spec for rendering a table of cats that are up for adoption. The server lets you vary the number of cats in the table from 1 to 10,000+. Here's what the output of the server looks like:
| Name | Colour | Sex | Legs |
|---|---|---|---|
| Maggie | Brown Mackeral Torbie | Unknown | 3 |
| Lucky | Seal Point with White (Mitted Pattern) | Male | 4 |
| Minka | Silver Mackerel Tabby | Female | 4 |
| Millie | Solid Chocolate | Unknown | 2 |
| Kitty | Blue Classic Tabby | Female (neutered) | 4 |
The server can generate this table in two different ways.
The first way the server renders is a classic server-side template. Go templates are pretty fast and the results are served compressed and chunked, so I think this is a reasonable proxy for "the best you can do":
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Server render</title>
</head>
<body>
<table>
<thead>
<tr>
<th>Name</th>
<th>Colour</th>
<th>Sex</th>
<th>Legs</th>
</tr>
</thead>
<tbody>
{{range .}}
<tr>
<td>{{.Name}}</td>
<td>{{.Color}}</td>
<td>{{.Sex}}</td>
<td>{{.Legs}}</td>
</tr>
{{end}}
</tbody>
</table>
</body>
</html>
The second way the server renders is with the new HTML5 template tag used by frameworks like Polymer and Web Components. The server generates a blob of JSON and does all rendering from that data client-side. The only server-side templating required is injecting the JSON serialized data into the HTML shell:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Template tag render</title>
<script>
var data = {{.}}; // The JSON data goes here
</script>
</head>
<body>
<table>
<thead>
<tr>
<th>Name</th>
<th>Colour</th>
<th>Sex</th>
<th>Legs</th>
</thead>
<tbody>
<template id="row">
<tr><td></td><td></td><td></td><td></td></tr>
</template>
</tbody>
</table>
<script>
var template = document.querySelector('#row');
for (var i = 0; i < data.length; i += 1) {
var cat = data[i];
var clone = template.content.cloneNode(true);
var cells = clone.querySelectorAll('td');
cells[0].textContent = cat.name;
cells[1].textContent = cat.color;
cells[2].textContent = cat.sex;
cells[3].textContent = cat.legs;
template.parentNode.appendChild(clone);
}
</script>
</body>
</html>
Notably, neither of these pages has any external resources. I wanted to control for that variable and understand the best you could do theoretically with either approach.
Browser setup
I tested the two test pages in two different browsers.
The first browser is Chrome Desktop version 39.0.2171.99 on Mac OS X version 10.10.1; the machine is somewhat old, a mid-2012 MacBook Air (2GHz Core i7, 8GB RAM, Intel Graphics). The second browser is Chrome Mobile version 39.02171.93 on Android 4.4.4; the device is top of the line, a OnePlus One (Snapdragon 801, 2.5GHz quad-core, 3GB RAM, Adreno 330 578MHz). Granted, this is a high-end mobile device, but it's also one of the cheapest out there — I wouldn't bet against Moore's law (especially with what's happening to Samsung).
On desktop, the page loads were done directly to localhost:8080, eliminating any concerns of network overhead. On mobile, I used port forwarding from the Chrome DevTools to access the same localhost:8080 URLs.
Content size
Here's a chart of the size of the content as a function of the number of cats on the adoption page (note that this log-scale on the X axis and log-scale on the Y axis).
What I see in this graph:
- The page that uses JSON is smaller than the HTML page
- But the compressed size only varies by 10-20% at most
Conclusion: Response sizes don't matter if you're using compression.
Server response time
Here's a chart of the server response time as a function of the number of cats on the adoption page (again this is a log-log chart on both axes). This is the time it takes for the Go server to render the template without actually loading it in a browser. I measured this time with curl -w '%{time_total}\n' -H 'Accept-Encoding: gzip' -s -o /dev/null URL.
.png)
What I see in this graph:
- The pages are about the same performance until you get to 250 cats
- Above 250 cats, the JSON page becomes increasingly faster (5x for 10,000 cats)
Conclusion: The page that uses JSON is faster at higher numbers of cats likely because there's less data to copy to the client. But this latency is small enough and similar enough (JSON vs. HTML) that it can be ignored when comparing overall render time.
First & last paint time
This is the most important thing to measure. Essentially, PPK's argument comes down to the critical rendering path. That is: How long from when the user starts trying to load your webpage in their browser to when they actually see something useful appear on their screen?
Measuring the time from "request to glass" is pretty well documented these days. Ilya Grigorik gave a great talk at Velocity 2013 about optimizing the critical rendering path. Since then the same content has been turned into helpful documentation. Chrome even provides a window.chrome.loadTimes object that will give you all of the timing information (see this post for details).
I added instrumentation to the templates above to console.log two numbers:
- Time to first paint: How long between the request start and drawn pixels on the screen. Importantly, the page may still be loading (via a chunked response) when this happens.
- Time to last paint: How long between the request start and the page fully finishing its load and render. This is the time after all resources have loaded, all JavaScript has run, and all client-side templates have inserted data into the DOM.
I ran each timing test 5 times to account for environment variations (like GC pauses and random system interrupts).
Results: Desktop
Here's a chart of time to first paint on Chrome Desktop (log-scale X axis).
.png)
Here's a chart of time to last paint on Chrome Desktop (also log-scale X axis).
.png)
What I see in these graphs:
- The first and last paint times for the JSON/JavaScript approach are the same (as expected)
- The first and last paint times for the server-side approach are different because the browser can render HTML before the whole chunked response has finished loading
- Up to 1000 cats, there is practically no latency difference on Desktop between client-side rendering with JavaScript and server-side rendering with dumb HTML
- Above 1000 cats, the server-side rendered approach will do first paint well before the client-side approach (3x faster in the case of 10,000 cats)
- However, the client-side rendered approach will do last paint well before the server-side approach (2x faster in the case of 10,000 cats)
Conclusion: It depends on what you're doing. If you care about first paint time, server-side rendering wins. If your app needs all of the data on the page before it can do anything, client-side rendering wins.
Results: Mobile
I repeated the same painting tests for the mobile browser.
Here's a chart of time to first paint on Chrome Mobile (log-scale X axis, and note that the Y axis is 0 to 10 seconds instead of 0 to 2 seconds used in the desktop charts above).
.png)
Here's a chart of time to last paint on Chrome Mobile (also log-scale X axis and 0 to 10 second Y axis).
.png)
What I see in these graphs:
- Everything is about 5x slower than desktop
- There's a lot more variance in latency on mobile
- Performance up to 1000 cats is roughly the same between server-side and client-side rendering (with up to a 30% difference in once case; 15% or less otherwise)
- Above 1000 cats, the server-side rendered approach has a lower time to first paint (up to 5x faster) just like desktop
- The client-side rendered approach will do last paint well before the server-side approach (up to 2x faster) just like desktop
Conclusion: Almost the same comparative differences as client- and server-side rendering on desktop.
Summary
Is PPK correct in saying that "client-side templating is wrong"? Yes and no. My test pages use the number of cats in the adoption table as a proxy for the complexity of the page. Below 1,000 cats worth of complexity, the client- and server-side rendering approaches have essentially the same time to first paint on both desktop and mobile. Above 1,000 cats worth of complexity, server-side rendering will do first paint faster than client-side rendering. But the client-side rendering approach will always win for last paint time above 1,000 cats.
That leads to two important questions:
1. How many cats worth of complexity are you rendering in your pages?
For most of the things I've built, I usually don't render a huge amount of data on a page (besides images). 1,000 cats worth of complexity in the data model (which corresponds to ~75KB of JSON data) seems like quite a bit of room to work with. For example, the Google Analytics page I linked to above only has ~30KB of JSON data embedded in it for initial load (in my case).
After the first load, modern tools make it trivial to dynamically load content beneath the fold. You can even do this in a way that doesn't render elements that aren't visible, significantly improving performance. And I'd say optimizing the size and shape of the first render data payload is straightforward.
Practically speaking, this all means that if your first load is less than 1,000 cats of complexity, client-side rendering is just as fast as server-side rendering on desktop and mobile. To me, the benefits of client-side rendering (e.g., UX, development speed) far outweigh the downsides. It's good to know I'm not making this tradeoff blindly anymore.
2. Do you care about first paint time or last paint time?
With Google's guide on performance, Facebook's BigPipe system, and companies like CloudFlare and Fastly making a splash, it's clear that some people really care a lot about first paint performance. Should you?
I'd say it really depends on what you're doing. If your business model relies on showing advertisements to end-users as soon as possible, time to first paint may make all the difference between a successful business and a failed one. If your website is more like an app (like MailChimp or Basecamp), the most important thing is probably time to last paint: how soon the app will become interactive after first load.
The take-away here is to choose the right architecture for your problem. Most of what I build these days is more app-like. For me, time to first paint doesn't matter as much as time to last paint. So again, I'll stick with the benefits of client-side rendering and last-paint performance over server-side rendering and first-paint performance.
Conclusion
My conclusion from all this: I hope never to render anything server-side ever again. I feel more comfortable in making that choice than ever thanks to all this data. I see rare occasions when server-side rendering could make sense for performance, but I don't expect to encounter many of those situations in the future.
(PS: You can find all of the raw data in my spreadsheet here and all of the test code here)
(PPS: If you're particularly inspired by this post to adopt a cat, check out the ASPCA)