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.
- 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.
- 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.