Many of the articles on this site will go in deep into one topic or another, and assume you know the basics. This sticky article is a good primer for understanding the basic of Website Performance and Hosting Performance.
The faster your website loads, the more satisfied your visitors are. This leads to more engagement with your site, improved conversion, and more. It’s assumed you agree with this, faster is better, right? Okay, moving onto the basics.
Google Analytics is a must for traffic analysis, understanding paths customers take through your site, tracking conversion rates and, of course, your site speed. Learn how to get 100% sampling for your site speed.
In the previous article, How To Compress Images; For Faster Site; Gtmetrix Trick, you use gtmetrix to get compressed images after they’re already live. Wouldn’t it better to compress images before use!? Yes.
There are a variety of image compression tools. There are online web services, desktop tools and even WordPress plugins that use online web services. The goal is the smallest possible filesize with minimal visual impairment. Let’s explore the ways.
WordPress WP Smush.it
If you use WordPress, highly recommend using the WP Smush.it plugin. Compressing images couldn’t be easier. Once installed, it intercepts non-optimized images and uses Yahoo Smush.it to compress images. It tells you how much it saved:
In this week’s article, I’m going to share a little trick for image optimization with Gtmetrix on your site. This trick for how to compress images works after a page is live. Better practice would be to always perform image optimization before build or update. But, if you’re like most of us, even though your intentions are good, the demand for getting your content to market supersedes getting nitpicky about compressing images.
So, what you do is, go to http://gtmetrix.com/ and paste in the URL to your page and click Go! The resulting page will look like this:
In the How to Compare Hosting Companies’ Speed & Reliability article, on the SYS-CON Media site, the best web hosting review method is explained. It’s speed and uptime, over time. In a nutshell:
Website speed test
- Deploy the same WordPress site to a bunch of hosting providers
- Measure speed and uptime with pingdom or similar
- Report results over time
The GoDaddy Web Hosting Performance team
The GoDaddy Web Hosting Performance team is the group within GoDaddy that is responsible for tuning our web hosting environment for peak performance. In order to do so, we measure the response time of a control page loaded on every one of our web servers, every 5 minutes. An Application Index (APDEX) score is calculated for every server, which rolls up to product location, to product to product group. The Hosting Operations Center team has a prioritized list of servers to investigate if a performance issue arises. The company has great situational awareness of the performance levels of its products and services.
Every server has a “control site” that we use for performance monitoring. The control site is a WordPress page on Linux and a DotNetNuke page on Windows. A headless browser simulates a full page load of the control site on a regular basis. Time to first byte and full page load times, and many other interesting metrics, are pushed into graphite.
From the graphite API, an APDEX score is calculated on every server. Listed in table format, sorted by APDEX, the Web Hosting Operations Center team has a prioritized list of servers, updated frequently.
Once in awhile, your site visitors wait for a cold cache DNS lookup time. The more popular your site, the less likely this is, and visa versa.
It’s hard to notice, because it only happens on first load per visitor per shared DNS resolver. When you experience it on your own site, the common reaction is to hit refresh and see if it happens again. And it doesn’t, so you scratch it up to ‘whatever.’ But is an extra [up to 1] second of page load time really what you want for your first impression? This article is about squeezing in one more performance enhancement by reducing the likelihood of visitors needing to wait for a full cold start DNS lookup.
If you’re running a Windows .NET web app, like DotNetNuke, it must be compiled by IIS before serving it up. When a page request comes in, IIS checks to see if the compiled bytecode is loaded in the iis application pool. If so, it uses it and if not, it loads all files and compiles them, puts them into the iis application pool, then serves the page.
We refer to this “wait while I compile the site before serving up the page” page load as the “cold start” page load. This can add 1-10 seconds of page response time, depending on how complex the .NET app is, the amount of disk i/o required, and how busy the web server is (i.e. available CPU) at the time of compile.
This article is meant to provide a tip to website performance enthusiasts for keeping their sites warm and reducing the likelihood of site visitors waiting for the “cold start” page load.