Everything is about speed these days, and user expectations are higher than ever. We no longer wait for information, we want it instantly, we want to consume it as quickly as possible it and move on to the next thing.
Having a slow loading site is a surefire way to hack your users off to the point they don't return - and what's the point of putting all of the blood, sweat and tears into a beautifully crafted website if it's slower than a herd of turtles stampeding through peanut butter. And the consequences are even more severe if your site sells a product, as we all know conversions are king, and slow page loads more often than not lead to slow conversions.
If that wasn't reason enough, Google have made no secret about the SEO implications of a slow page load, they even provide a handy tool for testing your page speed, it also provides a rather fine set of suggestions on how to speed it up. So if you value your rankings, and you value your users, read on!
Optimising a simple website for page load speed is easy, optimising large or complicated website... is not. There are two main areas you need to look at to increase the page load speed, and that's the backend and the frontend.
The backend refers to the server processing time to generate and output the page, which is affected by things such as the server specification and the quality of the code running the site. For example, a slow server, poorly written PHP code, or slow MySQL queries can all cause the page generation time to increase. If you're aiming for 150ms, then you've only got about 100ms for the server to generate the page, leaving 50ms for it to be sent and rendered in the browser. We'll look at optimising the backend another time, for now lets stick to the frontend.
Combination, Minification and Compression
So although your user maybe on the super duper fast as can be BT Infinity (other fibre optic based broadband products available) they may as well be on their Nan's dialup, because the fastest connection in the world won't help here. Why? Because it's not about bandwidth, it's about latency. A realistic example is that takes 20ms for your user to send data to your site's server, and your server takes 20ms to send it back. So for each file, it will take 40ms to request the file, and another 20ms to receive the file, and another 20ms to close the connection. And because each request is done sequentially, and you've got rather a long, and rather noticeable wait to get all of that CSS and Javacsript.
Doing the above will generate one single file, however, in most cases this will have become quite a large file size due to the amount of code in it, so this is where minifying and compression comes in.
Content Delivery and CDN
A global CDN (Content Delivery Network) can do the above for you, and with the added advantage of being global, it will cache and serve the files from POPs (Points of Presence) geographically closest to your user.
And that's Part 1 of our Frontend optimisation guide. In Part 2 we'll look closer at each item and explore the technical side in detail.
Truth be told, it’s difficult for a web application that doesn’t have some kind of identification, even if you don’t see it as a security measure in and of itself. The Internet is a kind of lawless land, and even on free services like Google’s, authentication ensures that abuses will...
Although data persistence is almost always a fundamental element of applications, Node.js has no native integration with databases. Everything is delegated to third-party libraries to be included manually, in addition to the standard APIs. Although MongoDB and other non-relational databases are the most common choice with Node because if you...