Edgar Kneel

A Practical Guide To Decrease Web Page Load Time

Why is it important for your pages to load fast you might ask.  The answer is easy; if your pages load slowly you will loose sales.  From a consumer perspective you have a fraction of a second to show activity.  Your page doesn’t have to load completely but they certainly need to see some activity right away. 

Why is it important for your pages to load fast you might ask.  The answer is easy; if your pages load slowly you will loose sales.  From a consumer perspective you have a fraction of a second to show activity.  Your page doesn’t have to load completely but they certainly need to see some activity right away.  Consumers are impatient and have been trained by the major sites that pages start displaying immediately.  If you don’t have fast loading pages, most consumers will go to the next site.  It’s not just consumers that value speed, major search engines have stated that it is important for pages to load fast if you want them indexed.  The faster page loads, the more pages you will get indexed.  Some search engines have come out and stated that they will even downgrade your paid search marketing if your pages load slowly.  What can you do to increase page load speed?  Below are the techniques I used to successfully decrease the time it takes to load web pages.

Web Server Optimization

SQL Server Optimization
The first thing to check is your disk using PerfMon (Windows Performance Monitor).  Use this to determine if your physical disk is keeping up.  Using PerfMon, select the PhysicalDisk object, Avg. Disk Queue Length counter, then the instance for the drive your SQL database is installed on.  This indicator count will vary based on if the drive you are monitoring is part of an array but it’s best to keep the average below 1 if possible.  See Microsoft’s documentation on this for more information especially when calculating for drive arrays.  http://support.microsoft.com/kb/146005

Next you want to check SQL memory usage.  By right clicking the server in Enterprise Manager and selecting properties you can view the Memory tab.  Use this tab to give as much memory as you can afford to SQL.  The more memory you give the SQL the more data it can cache, thus returning results faster.  Does your server have more than 2GB memory?  If so use this guide to configure your server to see all that available memory http://support.microsoft.com/kb/283037 then this guide http://support.microsoft.com/kb/274750 to configure SQL to see more available memory.  To make sure SQL is using available memory don’t use task manager as it may report incorrectly.  Instead use PerfMon Process Object, Working Set Counter, sqlservr Instance.  Give your server time to build up its cache after restarting before checking this counter.

You want to make sure your CPU can keep up.  Caution this counter can be misleading.  Although you may be recording sustained high CPU utilization this may not mean you need a faster CPU, the lack of adequate disk speed and memory may be artificially increasing CPU utilization.  If CPU utilization is averaging over 80% for an extended period of time and you have already ruled out memory and disk as an issue you may need to upgrade your CPU(s).  Use PerfMon to track CPU utilization using the Processor Object, % Processor Time Counter, and applicable instance if you have more than one CPU.  If your server has more than one CPU and you can afford to let SQL use more than one, right click on the server in Enterprise Manager, select Properties, and then the Processor tab.  This will allow you to select multiple or all CPUs for SQL utilization.

Bandwidth is a little more obvious but still needs to be mentioned.  If you have sustained high bandwidth utilization this will become a bottleneck causing slowdowns.  Bandwidth utilization can be a bit harder to check.  If you are using a hosting company they should be able to tell you (typically with some type of real time monitor that you can log into) what you are averaging with bandwidth as well as spikes in bandwidth.  You will want to make sure you have plenty of available bandwidth from your hosting company especially during the busy part of your day.  If your hosting company cannot provide these reports you can utilize a hardware or software sniffer to determine bandwidth usage.  The key is to make sure your connection can handle much more than you typically use.  If you are averaging 80% utilization you should consider upgrading your connection.

Now that you have checked the major hardware bottlenecks put your DBA hat on and make sure your indexes are up to date.  If you’re not an experienced DBA that knows the best way to manage your indexes, use SQL Profiler (Tools, SQL Profiler from Enterprise Manager).  Create a new trace and select the SQLProfilerTuning template.  Make sure the time you record is long enough to collect data on regular activity.  Additionally if you can generate additional traffic (especially traffic that causes slowdowns) you will want to do as much of this as possible while collecting data.  Once you have finished collecting data, click Tools, Index Tuning Wizard.  Use the profile you just created and make sure to select the database in question.  When finished running apply any changes suggested.  You may need to run this multiple times until there are not recommended changes.  Additionally as you make changes to your database such as adding new fields you will want to run this entire process again to find and apply new recommendations.  I like to run this process on the regular basis just make sure everything is running smooth.  As a side note, make sure every table in your database has a primary key. 

Once you have optimized your indexes run SQL Profiler again to check what kind of activity you are having on your SQL server. Do you have long running queries that could be changed to run more efficiently?  Do you have queries that are being run over and over that you could cache inside your website application?  As you make upgrades and additions to your web pages you many times will add extra queries to your database.  Go through your pages and find out if you can combine queries to return information with one query instead of two.  If you have to make multiple queries, try to make one connection to the database, and then use that same connection for all the queries.  This way you are not making repetitive connections to the database one after the other.  Making a database connection can be time consuming and resource intensive.

The way you partition your database across drives on your SQL server can help if you are suffering from high disk utilization.  The following configuration has worked well for me note that each partition is on a separate physical drive:
C: Operating System and SQL executables
D: Database File – RAID 5
E: SQL Log Files
F: Temp Database
G: Backups

Using RAID 5 on the D drive allows very fast reads because multiple drives can respond to the request.  Additionally requests do not have to wait for writes to the Log Files or Temp database.  Because the D drive is for read data, SQL can more effectively use memory to cache frequent requests.  There are a lot of write requests to the SQL log files and temp database so giving them they’re own separate drive reduces contention.  It goes without saying that using drives with higher RPM, more throughput, and a larger cache will assist your SQL server to run faster.

Web Server Optimization
Since almost every page the typical Internet retailer website has will make some type of database connection, your bottleneck will probably be retrieving data from SQL.  If this is the case you probably won’t need to do much optimization for your web server.  Generally speaking you will want to make sure the server has plenty of CPU, memory, and disk resources available to your web server.    Increasing memory to allow more web page caching (see caching section of this article) is one area you can really boost page load time.  Additionally if you find your disk having problems keeping up try some of the following:
1 Add memory and increase caching
2 If you have logging enabled, move the log file locations to another drive.
3 Make sure your web pages are being loaded from a RAID 5 partition.

Database Backups
I won’t go into all the specifics of database backups as that requires an article of its own.  From a question of performance you will want to schedule your backup to run when you have the most available resources.  If you are backing up to another server, consider backing up to a local drive first, and then backing up across the LAN.  This can help complete the backup faster because it’s done locally, then when transferring the backup to another server you won’t need to be concerned with how long it takes to transfer to another server.  Another option is to setup a separate server that you mirror data to, then you can simply backup the mirrored server instead of the primary.  This mirrored server can also be utilized as a fail over server in the case the primary server fails.

Load Balancing/Multiple Servers
If you are still having problems after you have optimized your web server, database server, web pages, and server hardware you can consider adding servers and load balancing these servers.  Since every situation is different it’s impossible to list every possible configuration.  Below are some examples but it’s important for you to do in depth research to determine  exactly what resources are lacking and what is utilizing those resources so you can make the best decisions on what type of servers to put up and how to load balance.

If you currently run a single server, determine what resources are lacking, probably disk or memory, maybe CPU and what is using these resources.  Typically when moving from a single server to multiple servers you will put in a new server and only put your database on that new server.

Next I’ll show you a configuration with three servers that has worked out exceedingly well for me:
Each server has SQL and IIS installed.  We have one master server and two slave servers.  The master server has our entire database on it, the websites can write orders to this database and our staff can process orders using this database and we keep vendor inventory records up to date on this server.  The master server is the only server that gets backed up.  The two slave servers are setup so that only the parts of the websites and database that are needed for the public to use our websites are replicated.  Therefore any change that is made to the master server is replicated to the slave servers within 15 min. of the change.  Because the public websites write back to the master server the slave servers can run in a “read only” mode which allows them to process an enormous number of requests very fast.  Because our master server only receives writes from the public websites when orders are being taken, it only has to handle a small amount of our public traffic.  As our traffic grows we simply add more read only servers.  In our case we have enough websites that we simply split them up between servers.  If however you have a single website, you can still load balance using a DNS round robin or in more extreme situations an appliance like F5 Big IP http://www.f5.com/products/big-ip/ which can perform smart load balancing based on current server load.

Another popular method is to setup multiple SQL servers (assuming this is the main bottleneck) with separate data.  For instance if you keep your images in SQL, you may want to move them to they’re own server then make a connection to one server for some of your data and to the other server for retrieving images.

Web Page Design

Java Script and CSS Files
Putting Java Script and CSS in files instead of inline allows your browser to cache them instead of reading them each time.  Since your browser has to download each file separately, do your best to keep all your Java Script in a single file and do the same with CSS

Image Optimization
Optimizing images is very important in page load time.  Convert your images to PNG.  Don’t use HTML to resize your images, resize and optimize them prior to uploading.  Try to keep your larger images to a file size under 30K if possible.  There are some advanced optimizations that can be done with inline images, sprites, and image maps but I am not experienced with them for the most part and in many instances management of this can be a nightmare.  Additionally there may be browser support issues. 

Caching
Caching is one way to drastically reduce page load time, especially for popular pages.  Even if your page is dynamic, you may be able to cache it for 4 hours or at least 15 min. 

You can enable browser caching by using the HTML Expires heading for any pages that can cache.  This type of caching tells the visitors browser that if it returns to this exact page it’s doesn’t need to go back to the web server and retrieve the page again.  This will help when people are browsing your site and come back to the same page multiple times.  If the page is more static, like an article page for instance, you may be able to set it to cache for 30 days.  This will allow the same person to go to that page different days without having to hit your server.  The downfall of this caching is that it only helps if people visit your page more than once within the caching time.

Another type of caching is server side page caching.  This allows you to cache a page on the server instead of the browser, therefore when defining the caching time, anyone that requests the page inside of the cache time will receive the cached page.  Server side caching will allow your web server to cache the page in memory (given there are enough memory resources available) which means it does not have to go to the disk to retrieve the page or query the database.  Let’s say for example the front page of your website has a tree view menu that makes multiple database queries to build the page.  If this page is requested many times an hour it will generate a lot of resource strain on your servers.  If you set this page to cache for 15 min. you now only create that resource strain once every 15 min. allowing your server to respond better to other requests and your page will display much faster.  Of all the things you can do to make your site faster, this may have the biggest impact. 

Similar to server side page caching is partial page caching.  This is a little more complicated but allows you to cache parts of your page.  Let's use the example above again but this time the criteria mandates that we can’t cache everything in the page.  In this case we may want to just cache the menu as the menu is relatively static and is a large resource drain on the servers and slows down page delivery.

Separate Domains
Some browsers will open multiple connections to download files simultaneously but will have a limit to how many per domain it will concurrently download.  To get around this you could move files like Images, CSS, and Java Script to separate domains thus allowing the browser to download more files simultaneously.

Progressive Rendering
Progressive rendering is when you visit a page and you start seeing parts of the page display right away instead of displaying the entire page at once.  This process gives the user feedback right away and they know more is coming.  If your page takes a second or so before it renders to the browser, the user may thing there is a problem and instead of waiting will move to a different page.  Progressive rendering can also give the illusion that the page is loading faster even though it takes the same amount of time to completely render the entire page.  To progressive render your page you may need to tell your back end programming language to pass parts of your page as they render.  Additionally with components like an ASP.NET Gridview you cannot progressively render that component, instead it will render than entire object all at once.  From an HTML perspective you will want to make sure style sheets are loaded in the page head and Java Script is loaded at the end of the page.  Not doing this can prevent your entire page from progressively rendering.

Large Classes
One of the benefits ASP.NET is using extremely rich classes like the grid view.  You could dedicate a complete book (and I’m sure someone has) to explore the features and inner workings of the grid view.  It’s extremely flexible and easy to use.  With a couple simple queries you can define a simple editable grid view.  One cost of using the grid view is that because of all that’s built in it carries a heavy payload.  Many times this is not an issue but you will notice a speed increase for simple display grid views if you generate the HTML and render it in a table or some other rudimentary display manner.

Compression
Remove excessive white space in your rendered code will reduce the size of the data being transferred, thus speeding up the page load time.  Additionally configurations can be made to most web servers to support GZIP (a GNU Compression Utility) http://www.gzip.org/ this can easily cut the size of what you are transferring in half or more.  This involves extra CPU cycles on the server to compress and on the browser to decompress but unless your server is running sustained high CPU utilization you shouldn’t see much of a CPU hit or slowdown because of this.  On a side note, utilizing this compression could cut the bandwidth portion of your hosting bill in half or at least free up extra bandwidth.

Website Errors
Errors will slow everything down, not to mention annoying your customers.  Every time your back end code or web server has to engage error processing it takes extra resources away from your server.  Capture coding errors using error control is the first step.  As a common practice I have all errors emailed to me so I am forced to see them and mentally acknowledge them.  This also helps me judge the frequency of the errors.  Because I am always seeing them it’s usually on the top of my list to get them fixed.  Over time coding in fixes for all the possible errors will prevent error control from having to engage as often thus increasing overall performance.  The other errors you will want to keep track of are the web server errors such as 404 (Page Not Found).  You can track the occurrence of these errors in your server web logs.  If for instance, there is an old link to a page that no longer exists, instead of letting the web server generate a 404 error, place a file (same name and location of the missing one) with a friendly “does not exist” message or a script to redirect to another page on your website.

There are certainly many additional things you can do that don’t fit the scope of this article.  This is meant as a practical guide for the small to mid size Internet retailer.  I hope you have found this informative and at lease consider each one of these techniques before exploring more in-depth or expensive solutions. Here is a free Web Page Load Time Tracker http://loadtimetracker.internetretailerblog.com  that you can use to monitor the speed at which your pages load over time. This resource is unique in that it uses an actual web browser to render the page including downloading and displaying CSS, Images, and JavaScript.  Set this up now on all your different pages so you have data to chart against when you make changes to your site.

Article Tags: Page Load Time, Page Load Time , Practical Guide, Page Load, Load Time, Pages Load, Make Sure, Sustained High, Hosting Company, Many Times, Load Time , Master Server, Slave Servers, Java Script, Server Side, Grid View 

Source: Free Articles from ArticlesFactory.com

ABOUT THE AUTHOR