As internet speeds increase, users expect a web page to load in a timely manner. Research shows that delayed response times of even 1 second can result in 7% less conversions, therefore as a developer it is important to consider page load times (not just when a single user is accessing the site but under large loads as well) during the architecture stage and not after the fact when changes may require significant refactoring.
When creating a web site, it is easy to get caught up with optimization at the code level alone. JavaScript libraries such as AngularJS along with AJAX?for data access can deliver a speedy web site with minimal server-side processing. However the code is only the beginning and there is a whole ?stack? of factors that can affect the page responsiveness and load times. If the database or network can?t handle increased requests it was all for nothing. The following items are a very high level overview at how the stack affects page load times:
- On page elements are probably one of the simplest changes that can be made (even after a site has already gone live). By using the YSlow browser add-on, the number of HTTP?requests and their sizes can be optimized to create a smaller footprint. By combining and compressing both JavaScript and CSS, putting CSS images together in a sprite, and compressing other images: the number of HTTP requests (and their size) goes down which directly leads to faster page load times. A mobile specific or responsive web design has also become more important as mobile/tablet users are growing every year, in some cases the desktop market-share is less than that of mobile/tablet browsers.
- Information architecture is not only important to the user experience, but can also affect the page load times. If users have to make several page loads or hunt to get to key pages/resources it exponentially increases the load on the server at any given time, and causes slower page load times for all users. Architecture of web pages and site navigation can be used to highlight key information that users might be looking for, which gets them there in fewer clicks (page loads). SEO with search results and even paid advertising campaigns can also be effective in simplifying the user journey. The goal here is to take out unnecessary page loads and get the user the content they require, all while taking pressure off the web stack which correlates to faster load times. Adaptive design should also be considered to tailor the content to the type of user browsing the web site.
- Code architecture is optimizing the code (C#, JS, SQL, etc.) required to serve a given page on the web site. Tools such as Redgate?s ANTS Performance Profiler can be used to see how long each piece of code or SQL takes to execute, which is useful for pinpointing slow running code. It is also recommended to run the SQL Profiler when there is load on the web site as well, to ensure code performance does not suffer in this case. There are many different ways to optimize slow running C#/JavaScript and database delays can be fixed by running an execution plan on slow running SQL and following the recommendations (it is often as simple as a new index).
- Web server setup encompasses a number of different elements:
- Server resources: when under expected load does the server utilise all of its CPU, RAM and Disk read/write (this can be monitored with Performance Monitor). If so vertical or horizontal scaling may need to be investigated, alternatively any services (including search) could be separated onto a separate server. CMS users may have licensing implications that can prevent horizontal scaling.
- Caching: there are many different caching options available on a web server. Output caching at the IIS level can lead to faster page load times, as does user control/page level caching at the web site level. However when using a CMS, they often have their own built-in or recommended caching setup that should be investigated first.
- IIS, APP Pool and Machine configuration: a number of different settings can be configured to control how the worker process(s), CLR thread pool and external connections handle the code processing. In most cases, the default configuration is optimal, however if you notice that calls to external services are slowing down code completion, you may look at increasing the max connections to that resource. If server resource usage is not maxing out, but there is a queue waiting for threads to process code, then a web garden at the application pool level may lead to much faster page load times.
- Database setup/configuration: min and max server memory should be checked to ensure there are no restrictions on memory usage, as should the user connections setting ? to ensure there is no limit on the number of users that can connect to the database concurrently. ANTS Performance Profiler can also indicate how long each SQL query takes to run, the longest running queries should be investigated to see if they can be improved.
- Network architecture: is a very generic term that can cover a lot of different elements. A quick test to see how it affects your page load times is to measure the average page load time with x users when connecting directly to the web server (via hosts file) and again with x users when connecting externally (through all the network infrastructure). If there is a considerable difference in the average load times, then there is something in the network infrastructure which is causing longer page load times.
- Caching: Caching at a higher level than the web server is a great way to dramatically reduce page load times. Both static files (PDF, CSS, JS etc.) and dynamic files (the content/pages) can be cached, the configuration often depends on how often content is updated and big wins can be had from simply caching the static content. Caching can be done by an internal appliance such as a load balancer or hardware appliance, alternatively an external service such as Akamai, AWS or CloudFlare can also be utilised (with the added benefit of global content delivery servers).
Alone each of the elements in the stack above may only contribute a small percentage to the overall page time. However when optimized at every level, the reduction in page load times can add up very fast ? and when an additional second in page load time loses 7% of conversions, the results will be noticeable to the business and end user alike.? As a developer you also need to be aware that load times may not be very different when its 1-2 users are accessing a web site, but once under load of several hundred (or thousands) the differences are much bigger and likewise are the savings with optimization. Like most architectural decisions, it is best case to look at this stack before the development phase rather than a Band-Aid solution once the web site has gone live ? this ensures the most value can be gained from each area.
Does your web site have high load times? Does it not handle user load very well? Diversus has a number of technical consultants that can work with you to identify and fix any performance problems which ultimately will lead to more conversions and a better user experience.