At the end of the day, what you want is a faster loading web site that will help your company achieve an objective.
For example, when I started working to make Geekzone a faster web site, our metrics included reduce web page load time, increase number of repeat visitors, increased time spent on site and increased number of page views - we don't sell a "product", we sell advertising after all so those were the important metrics for us.
Using tools like WebPageTest allowed us to measure the time a web page takes to load in different parts of the world. Even though 40% - 45% of our traffic is New Zealand-based, we still have a large number of visitors coming from overseas (including the United States, Australia, Canada, the United Kingdom and India).
A couple of years ago our average web page load time was around 10 seconds for a visitor coming from the US. By following through with changes in our database, backend scripts, hosting provider, CDN we managed to reduce the web page load time to around 6.5 seconds on average when measured from Dulles, VA.
With automatic web optimization software (in our case Riverbed Stingray Aptimizer) we managed to reduce the time even further to 4.5 s as you can see in the image below, captured from a WebPageTest run earlier today:
If you are in New Zealand our web page load times are even lower, on average 1.5 seconds for a complete page to be ready to be used.
In another post I will talk about each of the items we touched when improving performance on Geekzone - make sure to subscribe to my RSS feed. Of course if you run a web site and think a Web Performance Optimization project could help you improve metrics, please contact me and we can work on this.
Continuing my series of posts about Web Performance Optimization (WPO), here is another thought: use a Content Delivery Networks (CDN) to speed up web pages and save money.
Even though bits travel fast, it all comes down to distance and number of bits. The closer you are to your users, the faster your web pages will load. That's where CDNAs help us, web site owners. While a robust web site might have geographically distributed content servers for performance and redundancy, maintaining this infrastructure comes at a cost.
CDNs provide a balanced distribution platform that allows content providers to store resources closer to their clients, making everything a bit faster. Here at Geekzone we currently use MaxCDN, but played with Fastly and Amazon Cloudfront. We currently have mixed DNS and CDN solution (which I will expand on in another post).
CDNs can be used in many different ways. The most common are Push and Pull. With Push CDNs you are responsible for loading your web resources to their servers, while Pull CDNs will automatically retrieve your web resources from a nominated origin server when a request first comes in.
Below is the stats panel for one of our CDN configurations with MaxCDN, where you can see how the content is distributed through the nodes and how much data is used up every day:
And below you can see the traffic (in number of hits) including cache hits and non-cache hits:
Coming from New Zealand, where data traffic is usually one of the highest costs in a web site operation, CDNs have the side effect of helping web site owners save on traffic. You can see that our CDN serves something between 400 MB and 1.2 GB a day, depending on traffic, with 90% cache hits. This means 90% of the requests are served from the CDN caches directly, without ever reaching our servers.
CDN configuration can be as simple as just creating new DNS records pointing a resource domain to the CDN subdomain created for your specific configuration. If your web site doesn't currently use a separate domain for serving up those resources (images, scripts, CSS, static HTML) there are solutions that can automatically rewrite those when a page is requested.
When using a CDN it's important to make sure your web resources are correctly configured to appropriate cache expire and public caching. If this is not possible to configure in your server, there's always a setting on the CDN that will allow you to override settings from the original server with new default values.
In another post I will talk about latency - make sure to subscribe to my RSS feed. Of course if you run a web site and think a Web Performance Optimization project could help you improve metrics, please contact me and we can work on this.
Continuing my series of posts about Web Performance Optimization (WPO), here is a thought: focus on high impact web pages first. This might seem obvious when you read it, but from my experience most people don't actually put limits to a WPO project and over time the benefits are diluted.
The first thing to do is to identify possible candidates to a WPO project. In a previous project we found out one single script was hit with requests 80% of the time. We (the web site owner and myself) decided to concentrate efforts on this web page first.
Basically, we apply the Pareto Principle and concentrate our efforts on that page responsible for 80% of the total requests using only 20% of the overall time of a full WPO project, with more immediate results. We then have time to concentrate on the other 20% of pages which could take up to 80% of the project time, if needed.
Obviously if you have a page that is hit only a few times a day but still manages to bring the whole web site down, then this should be looked at too.
The tools of choice for this part of the project are web site analytics (Google Analytics is my favourite one - it's free!). Data needs to be collected for a while to help determine the exact focus of the sub project.
Once a web page is selected then a holistic approach takes place. Waterfall diagrams (I will talk about these in another post later) can be used to determine the balance of back end and browser side load times, helping determine which side needs more urgent attention. Scripts can be used to monitor events and report back with signals that can be used to determine specific areas causing slow rendering on the client side.
I will keep posting in this series - make sure to subscribe to my RSS feed. Of course if you run a web site and think a Web Performance Optimization project could help you improve metrics, please contact me and we can work on this.
For the last couple of years I worked on Geekzone to improve web performance, with great results. The thing that started me on this path was our limited computing resources at the time and a desire to use these resources in the best way possible. From there I found out more and more about Web Performance Optimization and accumulated some tricks that could help some of you out there.
There are so many variables in web performance that in most cases just adding more CPU power or memory won't necessarily speed up the user experience on the other side of the wire. That is because most of of the time spent by a web browser loading a web page is due to factors other than the server's processing capability. Steve Souders says 80% - 90% of the end-user response time is spent on the front end.
Any time a web page takes longer than a couple of seconds to load there is a chance the visitor will simply close the window or navigate away to another web site. In some cases this is reflected in lost sales. The faster your web site, the easier it is for customers to transact with your business.
While web site designers and developers can't control the line speed at the end, they can control what's loaded on the browser when their web pages are rendering. Being smart about it is how we implement web performance optimization.
There are of course things that can be done on the server side as well. Recently I was asked by a friend to find out why his retail web site was performing so badly, and why on peak time his Microsoft SQL server would just grind to a halt, most of the times requiring a few reboots daily. This obviously was something on the server side, not on the client side.
First I found out his server was running on a virtual environment with minimum memory, causing the database server to spend most of the time swapping things between memory and disk. I also looked on his Google Analytics reports and found 80% of the traffic was landing on a single script, which we agreed to concentrate the work on. I found things such as a "SELECT *" query over a table containing a few million records with a long "WHERE" clause and similarly long "ORDER BY" clause - and not a single index defined in the entire database. And this sort of query was used about ten times in that page alone.
Needless to say, working on that script was enough to practically solve the server side of the problem. And solving the server problem also improved revenue, since there were no more lost sales due to server crash, slow response times, etc.
But sometimes things are not that clear and the boundary between server and client performance is fuzzy. In some cases web and database servers are working just fine and a web page still takes a long time to load. That's where Web Performance Optimization projects come in.
I've created a new Web Performance Optimization category in my blog and I will start posting small tips and comments about tools I have used.
Of course if you run a web site and think a Web Performance Optimization project could help you improve metrics, please contact me and we can work on this.