Writing Desk


The Need for Speed

Race car

Site speed is obviously an important part of a website's success or failure.  While you may be willing to sacrifice speed for a neat effect or feature think about yourself as the user.  When was the last time you waited for a website to load and then thought "that was slow but (insert feature name) was really cool and worth the wait".  Never.

The hard reality is that sometimes we get overly obsessed about "cool" and lose site of usability.  And at the end of the day usability is what matters most because that effects whether visitors return or not.

The statistics on speed and it's affect on user behavior is nothing new.  According to Kissmetrics 47% of users expect a site to load in 2 seconds or less and 40% abandon sites that take longer than 3 seconds to load.  It took you longer to read those 2 sentences.

In 2016 Google officially announced it would start using mobile page speed in its ranking algorythm.  This means that as of now a slow site is going to start hitting you in the search results.

Measuring "Slow"

Slow can be a subjective term but thanks to Google PageSpeed it's super easy to measure and get some insight into improvements you can (and should) make.  You simply enter your URL in and Google will scan the page and measure load times.  When it's done it gives you a score (0-100) and a list of issues it found.  The issues are weighted so you'll know what is most important.  It's worth noting that getting a score of 100 isn't the goal.  I've never seen a site with a perfect score.  You have to balance speed with function to get the best of both.

What to Do

Let's talk about what the top three "speed killers" are and how you can fix or reduce them.

1. Image Size

The most consistent speed issue is overly-large images.  Bigger images equal bigger file sizes.  When browsers are forced to fetch large images and downsize them for display you're spending time retrieving "pixels" that never get seen.

To fix this browse your key pages and determine the rendered image size.  Then resize your images to that size and replace the large one.  While you're at it play with the image quality settings to further reduce the file size.  I find that for most JPG images I can save at 80% quality without noticeable effect.  If you're using really nice stock photography or professional photography make sure you're saving it for web use (which further optimizes the filesize).

2. Render-blocking CSS and Javascript

Browsers can only request a certain number of resources at a time (concurrent connections).  For the sake of example let's assume that most browsers can only handle 6 concurrent connections (a real number for most browsers).  The request for a particular page is 1 request but that page is also going to need to load CSS (your site's stylesheets) and Javascript.  Each CSS and Javascript file add 1 more connection.  And each image on a page uses a connection.  Those 6 concurrent connections fill up fast and then more are fetched - all while the user is waiting.

The browser doesn't render anything to the user until all the CSS and Javascript required in the page have been downloaded.  (There are some ways around this but those are beyond the scope of this article.)  This is what the render-blocking message refers to.  It simply means that users are having to wait for other resources to download before the page can be displayed.

The solution for this is to minimize the number of connections needed for CSS and JS and defer their loading as much as possible.  Admittedly it's quite difficult to completely eliminate this "issue" but it's impact can be greatly reduced.  In most cases you'll need to involve your web developer to help work through this but it's worth the investment - especially if Google PageSpeed gave you more than 2 or 3 offending resources.

3. Caching

It's obvious but often overlooked.  Cache longterm resources like your CSS, Javascript, and images.  By caching them subsequent page loads use the version stored in the browser instead of fetching them again.

Most sites can enable caching in their .htaccess file.  The .htaccess file controls a lot of what happens with your website so beware if you decide to edit it yourself.  One wrong item and your site will fail to load.

If you decide to add caching to your .htaccess file here's an example of what a simple caching solution might look like.

<ifmodule mod_expires.c="">

ExpiresActive on
ExpiresDefault     "access plus 1 month"

ExpiresByType text/css     "access plus 1 year"

# Favicon (cannot be renamed!) and cursor images
ExpiresByType image/vnd.microsoft.icon    "access plus 1 week"
ExpiresByType image/x-icon    "access plus 1 week"

ExpiresByType text/html    "access plus 0 seconds"

# JavaScript
ExpiresByType application/javascript    "access plus 1 year"
ExpiresByType application/x-javascript    "access plus 1 year"
ExpiresByType text/javascript    "access plus 1 year"

# Media files
ExpiresByType image/bmp    "access plus 1 month"
ExpiresByType image/gif    "access plus 1 month"
ExpiresByType image/jpeg    "access plus 1 month"
ExpiresByType image/png    "access plus 1 month"
ExpiresByType image/svg+xml    "access plus 1 month"
ExpiresByType image/webp    "access plus 1 month"