Website speed optimization
--
Website speed matters. Fast-loading sites perform better on all fronts: better user experience, higher conversions, more engagement, even higher search rankings.
Making sure a site isn’t losing customers due to sub-optimal site speed is part of an optimizer’s job description. If the site is slow, making it faster is a simple, quick way of getting an uplift. Typically the uplift won’t be huge, but every bit helps. It all depends on your starting point.
Site speed improvements are typically made either at the code level (front-end) or with the help of caching or a CDN. You don’t need to be very technical here (of course it would help), you can have any of this implemented by your front-end developers and IT / systems administrator.
How to check speed info in Google Analytics
Speed reports are under Behavior -> Site Speed.
As always, we don’t really care that much about the “average load speed”, but rather the load time of individual pages — especially high-traffic pages and pages that are part of your sales funnel.
Top metrics to look at:
- Average Document Interactive Time: How many seconds until the page is usable?
- Average Page Load Time: How many seconds to load the page fully?
Document Interactive Time is most important, as that’s how real users perceive page speed — how long it takes to render what’s above the fold. There might be a huge video and other stuff loading below the fold, but if people don’t see it right away, it won’t affect the perception of site speed.
See other speed metrics explained by Google.
Here’s when different stuff occurs in the web page rendering process:
The first bit (everything under page-load time, like redirection time and others) is mostly about the web host (the server your site is on) and DNS speed. Server response time should be under 200ms.
There are dozens of potential factors which may slow down the response of your server: slow application logic, slow database queries, slow routing, frameworks, libraries, resource CPU starvation, or memory starvation. You need to consider all of these factors to improve your server’s response time. If you’re on a shared web host, it might be time to upgrade onto a VPS, or dedicated server. If you’re already on one, consider upgrading RAM, CPU, and so on. Show your data to your web host and consult with them. Using caching and CDNs can really help.
Here’s a report for pages that get the most pageviews, and I compare whether the load speed is better or worse than the site average. All the pages that are in the red should get further analysis.
Now take those URLs and check them either under Speed Suggestions in GA, or enter the URLs to Google PageSpeed Insights tool. I took the worst-performing page from this list and entered it into PageSpeed.
Results:
The more errors you see here (especially red ones), the better! Now you can fix the issues and improve load speed. If everything would check out perfectly here, it would be harder to figure out how to improve speed.
Tools to evaluate site speed
Code improvement suggestion tools:
These tools will tell you about html/css, javascript, and caching improvements you need to make. Fixing the issues these two tools report (front-end code issues mostly) will give you a significant boost:
You might not be able to fix all issues, but all primary and medium importance stuff should get done.
Load speed measurement tools:
These tools will tell you how long each individual request takes — so you can identify slow-loading images and script, and either optimize them or remove them. Pingdom is my favorite one to use.
Here’s an example of results for the same URL I was analyzing above:
- 137 requests — Crazy! This needs to be cut down to like 30.
- Load time 3.28s — that’s all right.
- Page size 1.7MB — Clearly too large, especially for mobile devices in a non-wifi environment.
This is all useful info. Cutting the number of requests is mostly about combining css and javascript files, and using css sprites for images. But Pingdom allows you to figure out which items are the slowest so you can take some things off right away.
I looked at the waterfall report to see if some requests take a really long time (seconds), and found quite a few that took seconds to load! No page element or script should take over a second to load. Write down all the elements that take a long time to load, and see what are those about — and if something can be done.
Next — I look at the load time report:
If most time is spent connecting to the server, that means they’ve either got a slow web host/server or issues with their DNS (slow service provider, configuration issues). I would have some technical people investigate this issue further to determine which web host and DNS they’re using and whether that really is an issue.
Caching and CDNs
Caching can result in huge gains. The specific implementation will depend on which website platform you use. For instance, if you’re on WordPress, W3 Total Cache can really help. Consult your developers.
CDNs: You should serve all static resources — css, js files and images — via a content delivery network (CDN). It can really help you speed up the site.
Minimize round-trip times (RTTs)
RTT refers to all the requests required when a user accesses your website. RTT is the time required for a data packet to travel from a specific source to a specific destination and back again.
This is not a size of file issue, but a number of requests issue. Each asset that needs loading — css files, javascript files, images files etc — is requested individually. So your browser sends a request to the web server, which sends information back. The same for each file. That’s why an important strategy for speeding up web page performance is to minimize the number of round trips that need to be made.
Google has a handy manual for doing it all. Here’s a quick summary (have your web guys take care of it):
- Combine all your javascript files into one to minimize requests. If you’re technically inclined, check out Google Closure Compiler.
- Combine images with css sprites. The higher the number of images used on a page, the more roundtrips there are between visitor’s browser and the web server. Ideally you merge all tiny background images into one, and use css to show them. Your front-end developer (css guy) should take care of it. Some tools to create css sprites: Compass, SpritePad, Spriteme.
- Avoid css @import. Instead of @import, use a <link> tag for each stylesheet. This allows the browser to download stylesheets in parallel, which results in faster page load times.
- Minimize DNS lookups. Avoid using multiple domain names when loading a site.
- Minimize redirects. If needed, always use http redirects instead of javascript
