In this tutorial series we'll learn how to test your site speed, identify potential bottlenecks and issues that are slowing your site down, fix them, and also further optimise your site as much as possible. In Part 1 we'll look at how to speed test your site, and then how to analyse the results.
A bottleneck in a website is a certain item, or items that slow the loading of your site down considerably. Often removing or reducing these are your first task you should undertake to speed up your site.
To test your site you will use an online testing tool for analysing the website, it will generate a timeline and show elements of your site as they are downloaded when you load the page. The timeline is known as a 'waterfall' for reasons which will become obvious later.
There are many sites that provide speed testing and analysis, however for this tutorial we will use our favorite: webpagetest.org.
##Testing Your Site
Open webpagetest.org in another browser tab (so you can follow this tutorial at the same time).
Choose your Test Location - For a realistic test it's best to choose a location close to your main target audience location.
Choose your Browser - Unless you have specific reason to change this, it can be left as default.
Enter your website address and click the Test button.
Once the test is complete you will see your sites request waterfall, which we can now analyse.
##Analysing the Results
There are two ways to speed up a website's frontend, the first is to reduce and/or distribute the number of these requests, the second is to speed up specific requests. To begin we'll look at the components which make up a specific request and what they mean.
From the waterfall output there will be several colours you will see that will all represent the amount of time spent different steps that are undertook when downloading each item, we can analyse these below. As this tutorial series concentrates on optimising the frontend of your website rather than server side issues, DNS Lookup, Initial Connection, SSL Negotiation and Time to First Byte are explained below, but will not feature further.
####DNS Lookup (Dark Blue)
The amount of time it takes for your DNS provider to give your computer the IP address your website is using. If this is taking a long time you will need to look into your DNS provider (usually the same as your hosting provider) for the issue.
####Initial Connection (Orange)
The time it takes your computer to connect to your website's server, this is either down to the hosting server or down to your personal connection. If your site's server is busy, or your internet connection is at full capacity you may notice this is slower than it should be.
####SSL Negotiation (Purple)
This is because of your sites and servers configuration with SSL (https). This is normally safe to be ignored as minimal problems can occur here.
####Time to First Byte (Green)
How long the web server your site is hosted on takes to start sending the data. A delay here can indicate a slow web host, or in more common cases slow website code which is causing the page to be generated too slow.
####Content Download (Light Blue)
This shows how long the item is taking to physically download to the browser. If you've ever seen a large image on a website load slowly onto the page, then this will be the light blue bar crawling up behind the scenes.
####30x Response (Yellow)
This is a redirect, some redirects can't be avoided, for instance if you visit www.your-domain.com and it redirects you to your-domain.com (without the www). However excessive or unnecessary redirects should be eliminated as it causes the browser to perform an extra request. 30x responses look like this:
####40x Response (Red)
These are more serious errors, such as a request for a file doesn't exist or that there has been an error on the web server. These should be looked into as a priority as they can't be cached by the browser, meaning on each page load the server will request the same file and get the same error, using up valuable resources. From the 404 example below, you can see it took over half a second, all of which is wasted time.
##Speeding up Specific Requests
There are various techniques which can be used to speed up specific requests.
By default, any image formats used in modern computing (gif, jpg, png) are compressed already.
However compressing images isn't the only thing you can do. Images can be further optimised in
various ways. We won't go into the internals just yet, but it's possible to reduce file size by
a further 50% with optimisation tools.
Minfiying content means removing any unnecessary characters, whitespace and whatever else is
Computers don't need to see your code with spaces, line breaks, indents or comments, so by removing
these a considerable amount of file size can be saved.
All modern browsers can accept compressed content - literally a zipped up file. A browser is clever enough
to know when it's receiving such content and unzip it automatically. This reduces file size on average 80%. All
mentioned above that's done already for you, so you'll just end up wasting CPU resources on the server.
###Using Browser Caching
an expiry time for when the browser should discard the local copy, however in practise it's preferred to set an
expiry time many years in the future, and if you update an image you just need to change the filename so the browser
###Prioritising Visible Content
This more complicated technique involves ensuring any elements required for content
which is visible to the user when the website first loads are available on the first page
request. Consider what the user can see on your site without scrolling, this is what
appears to them initially - the aim is to get this to load as quickly as possible. To
do this you can use a technique called 'inlining'. See the next section.
###Inlining and/or Moving Render Blocking Code
when the page is requested. By doing this the browser doesn't need to wait for further requests to complete before
page until it's loaded should be placed inline.
##Reducing and Distributing the number of Requests
Reducing the number of requests can greatly improve a website's speed. Each element in the waterfall is a request, reducing the number of requests, or distributing them to a Content Delivery Network can greatly improve the loading speed of your site.
Combining files is one of the most effective methods to speed up a website. For each file request the users browser has to connect to the server, request the file, receive the file and then acknowledge it has the file. Often the connecting can take more time than the downloading of the file.
Image sprites is a technique for combining images into a single file. Consider a website which has 10 small icons, each icon would be a request to download. By combining all 10 icons onto a single file, and then using CSS to hide the majority of the file, only displaying the icon required in each place on the site, those 10 images have just turned into 1 request. This is what a typical image sprite looks like:
Try to imagine a small window over each icon, using CSS you can shut any of those windows leaving just the one icon on display.
###Content Delivery Network (CDN)
A browser can only make so many concurrent requests to a single server at a time. By placing some of your sites static assets onto a Content Delivery Network you move those assets to another server. The users browser can then download them in parallel with the rest of your website, rather than waiting for other requests to finish first.
A CDN is a large network of servers, which mirror your site files to locations all over the world. The CDN is very fast and global meaning your files get served quicker, at a geographical location closer to your user - a win for everyone.
##What Website Speed should I aim for?
There isn't a definitive answer to this question as there are many variables - website speed can't be quantified in a number. It's likely you've read this tutorial because you're concerned about your site speed, and the fact you're thinking about such a thing is a good indication that it's not as fast as it should be. Therefore the best judge of speed is yourself, once you're happy with how fast your site loads it's quite probable that it's fast enough.
This tutorial series will look at all of the things you can do to optimise your website. Take a look at this waterfall from google.com which is a great example of how optimised your site can become. The entire Google homepage loads in 11 requests, and although it may seem like a simple page to use as an example, Google has a lot going on behind the scenes.
By the end of this series you'll have enough knowledge to achieve something similar on your own website.
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...