It’s a well known fact that a static website will usually be faster than having everything running through a server-side language, like PHP or Ruby. Until a few weeks ago, the majority of the GoSquared site was still being generated by PHP code. Some of this code was as old as GoSquared itself and most of it had become obsolete, unnecessarily slowing down the site.
We recently replaced all this with a brand new static site.
Why?
Building your website using PHP encourages you to put a lot of logic and functionality within an HTML page, rather than thinking through exactly why that functionality is needed and how to implement it properly.
We’re also huge Node.js fans at GoSquared, and we wanted to have all of the account logic and administration in a Node.js application, which you’ll be able to read more about in future posts.
Maintainability
In HTML, CSS and JavaScript, we follow the concept of Separation of Concerns (keep all files separate and detached) to improve the maintainability of code – there shouldn’t be any inline CSS in your HTML. But we did have a huge amount of inline PHP, which is potentially even worse than any of the others.
Speed
Static HTML files are a lot faster than dynamic pages. Since release, we’ve seen a very noticeable decrease in page load times. We were also able to minify and compress all of the assets that make up those pages. View the source if you want to see – HTML is 20% smaller, CSS 17% smaller and JavaScript a massive 40% smaller. This has a huge impact, especially for our mobile users.
PHP can also be slow, and we knew we could speed things up by writing all admin functions in Node.js and making as much as possible asynchronous and parallel, while removing all PHP from the pages so there will be no server processing before page load.
Uptime, costs and scalability
S3 has an availability of ~99.99% and can handle any amount of traffic, so unless we make a serious mistake, the site should never go down due to high traffic. Having a few static files on S3 is a lot cheaper than running a small cluster of PHP servers, and much easier to manage.
We do still route all traffic through our nginx cluster, but that scales incredibly well. See our post on scaling nginx with Node.js.
How?
Serenity
Serenity is a static site generation framework written in Node.js (open source and available on NPM). I wrote Serenity as there was a lack of tools for developers who like to use EJS and JSON (rather than liquid and YAML). It’s basically Jekyll for JavaScripters.
It allows easy asset management, compression and is optimised for CDNs by providing asset path helpers which add a hash to the asset name so long cache TTLs can be used.
PHP include footer.php was replaced with <% include footer %> and there were the additional added benefits of layouts, templates, inline assets and much more.
We used layouts and includes extensively to provide a consistent site look and feel across all of the pages. One update to the signup form include will update every form on the entire site and regenerate the HTML accordingly.
Node.js
Node.js is fast, we already know that. It’s even faster if the functionality is planned and code is written to play to the strong points.
Account actions, such as logging in or signing up, are 4x faster than before. We were able to utilise the asynchronous nature of Node.js (and keep it tidy by using async) and therefore were able to fire off multiple concurrent MySQL queries (using node-mysql‘s connection pooling). Again, more on this later.
AJAX
The use of AJAX for logins and signups has made a significant difference too. There’s no longer a page reload before being told that you’ve mistyped your password.
Conclusions
We’ve really seen the benefits of converting our public site to be completely static. It’s faster, and our users’ experience is ultimately more important than the underlying code, so it’s a success already. On top of that, we’ve managed to build a maintainable system which we can update and improve long into the future.
What are your thoughts? Let us know @GoSquared on Twitter.
