This week, I focused on web site performance. I did some improvements to our service internally, but in this article, I will focus on the improvements to our public information pages. I used Chrome's built-in tool set as well as Web Page Test for my measurements. Now, I was already following some best practices, but the loading of our front page was still pretty bad. According to webpagetest.org, it was taking ~4.5 seconds for the first page to load and ~1.5 for a second page load. That is not horrible since I was enforcing SSL for my public information pages, but it was not good. So, after some research and redesign, I got the first page to load in about 1.5 seconds and the second to load in about 0.25 seconds. So, that is a three fold improvement in the first page load and a six fold improvement in the second page load. How did I do it?
I decided to stop requiring SSL for my public facing information pages. SSL negotiation can take a fair amount of time. Plus, if you are pulling resources in from third party sites (e.g., Google analytics tracking, Google fonts, Disqus comments, support tools, etc) those have to be SSL too unless you want your user's browser warning them there is insecure content on the page. These third party services each require their own SSL negotiation.
Now, when a user comes to the site, they can use HTTP. Once they decide to signup for the service, the form they submit uses HTTPS. In addition, once someone goes to sign in, they are directed to a Sign In page that uses HTTPS. For security, I do require HTTPS if they visit the public pages while still logged in to avoid session hijacking attacks.
I decided to remove dynamic elements for the public information pages. I used to have the 'Sign In' link change to a 'Sign Out' link. At times, I redirected the user to the home page and displayed a message. The disadvantage of this is that you cannot cache the page for any length of time (unless you use AJAX to update elements on the page). So I decided to keep the 'Sign In' link static and present messages to the user on pages internal to the service or on the Sign In page. This allows the public pages to be cached by browsers and intermediate proxy servers.
We use Zendesk as our help desk system. It provides a "dropbox" which is a widget you install on your web pages that allows customers to submit support requests. This widget took a fair amount of time to load, especially when I was enforcing SSL. I decided to have this widget only on the dedicated Support page since it was not really necessary on all the public facing information pages.
Lastly, I enabled HTTP caching for all of the public information pages that don't really change that much. This probably caused the greatest speed boost for second page requests since HTTP caching allows the browser's cache to be used.
I am very happy going from 4.5 seconds to 1.5 seconds on first page requests and 1.5 seconds to 0.25 seconds on subsequent requests. However, like any performance improvement, I could always do more. For example, I could switch to more compression for my images and start using image sprites. I could also look to load a fonts earlier in the page load process. But, right now, I am pretty happy with what I have.
What have you done to improve your site's performance? Do you have any specific questions for me? Please feel free to leave a comment! Plus, if you liked this article, please share it on your social network of choice.