When using the Cloudnode frontend in the past there was a noticeable lag. Two seconds for an average page didn’t seem normal. A quick analysis using Chrome’s inspector showed that over a second elapsed before the server started to stream content. This was clearly a server-side problem. Normally the server responds in half the time and testing several pages showed that some pages were served normally and some had delays. After some comparisons it was clear that the closure library used the extra time compiling the templates on each page view.
Optimizing Closure Templates
The pages are built in two steps. In the first step the template is compiled and in the second step it is rendered. Compiling the templates every time isn’t exactly necessary, but was done. The templates used for Cloudnode are rather complex with several levels of blocks, sections and widgets. The first optimization was done by precompiling all templates at startup resulting in half the rending times.
Fig 1: Server response time before precompilation
Fig 2: Server response time after precompilation
Optimizing the page speed
This step optimizes the transfer between the server and the client. There are several tools, including browser plugins and online services, that analyse your pages and give hints for optimization. The speedup tricks they recommend, are all similar: minimize and compress scripts and style sheets, cache static content and reorder scripts to minimize dependencies.
Page Speed - Nomen est omen
Google’s Page Speed gave us 63 out of 100 points before optimization. Following the hints to minimize and combine the scripts using the Closure tools resulted in some dramatic performance boost. Most static content is served by a Node.js 0.4.12 server using Express which does not offer compression. Fortunately there is a middleware called gzippo which jumps in and caches the compressed content in memory for fast delivery. Page Speed gives us now a 94 out of 100 and the pages are served in 500ms average time.
Fig 3: Google Page Speed