One of the basic requirements for a fast loading website is to have a web server that quickly responds to requests. While speeding up the origin response has a great direct business value, it can be quite challenging. In many cases it can be a lot easier to utilize caching in order to avoid the complexity of optimizing the server response time. However, caching a dynamic page is not a straight forward process.
No single blog post can really cover all what happens behind the scenes to load a web page, it is a mind dazzling process. Instead we will focus on the part where the browser is requesting the HTML source content from a server in order to load the page. We will also assume a simple single web server with a database.
When a browser tries to get the HTML source of a page it will issue a request to the server. The request will be routed through different routers on the Internet till it reaches the server. Depending on the geographic distance and network conditions, the routing time can take anything from 15 ms to 500 ms. The web server has no control over the routing time but a service like Akamai SureRoute can greatly improve this time. For static contents like CSS, JS and images, using a CDN is the best way to quickly serve the content from a server that is very close to the requesting browser. The other major time consuming part is the time it takes the web server to fetch data from the DB and construct the dynamic page. This time depends on many factors like how efficient the code running on the web server is, the response time for the DB, how big is the data in the DB, number of concurrent requests and so. This time can be as low as 100 ms for super optimized web servers and can go up to seconds. According to HTTP Archive, the median for the time to genereate a page is around 525 ms. Hunting the bottle necks that are responsible for slowing things down and speeding them can be extremely difficult and in some cases a full re-architecture of the entire application is the only solution. This is when caching comes to play. But how to apply caching for a page whose content keep on changing?
Many dynamic websites are not as dynamic as one may think. Because a page is using a programing language to generate the HTML content this does not mean the page is completely dynamic. Measuring how dynamic a page is can be done by tracking * how the page source changes when the page is loaded over time and by different users *. If the page source does not change when different users load the page and the page source does not change frequently overtime, then caching can be applied. An entire cache of an HTML page can be delivered through an edge server to the user. This way, when a user requests a page from a website, instead of going all the way to the web server, the HTML content of the page, along with its static resources will all be served from the edge server bringing the routing time to a minimum and completely eliminating the time used to build the page. Ravi Maira, provides more details regarding Dynamic Page Caching in a 5 min video.
We will continue with our approach of simple scenarios to get better understanding of the underlying concpet. Unless a page completely changes depending on the user seeing the page or overtime, chances are a good chunk and the more interesting information can be cached for a good period of time. Considering the simple page above, only the username and recently viewed items are dynamic. The rest of the core information on the page is static. The HTML source behind the page above probably looks something like this:
<html>
<head>
<link rel="stylesheet" href="123.css" >
...
</head>
<body>
....
<div id="user-details">
<p> Hi user 14156162 </p>
...
</div>
<div id="product-details">
How I Met Your Mother: Season 4
...
<div>
<div id="recent-products">
How I Met Your Mother: Season 2
How I Met Your Mother: Season 1
...
</div>
</body>
<html>
The first part of the HTML along with the resources in the HEAD section is the same for all users visiting the page, this part can be sent directly to the user while the web server is still constructing the content of the page. This allows the browser to utilize the time the webserver takes to respond to download the resources that will be needed later to render the page thus speeding the overlall loading time of the page. It would be even better if this top part is served from an edge server. Which is exactly what Akamai Edgestart does.
A personlized user experience can be achieved while still utilizing the ultra perforamce of Dynamic Site Caching. The above HTML source code can be rewritten like this:
<html>
<head>
<link rel="stylesheet" href="123.css" >
...
</head>
<body>
....
<div id="user-details"></div>
<div id="product-details">
...
<div>
<div id="recent-products"></div>
<script>
// make asynchronous ajax calls to retrieve user specific data and embed them inside the html source
.....
</script>
</body>
<html>
The above HTML source is the same for all users viewing the page, as it does not contain any user specific data, so it can be cached at the edge server. All the user data is loaded in a separate asynchronous AJAX request that does not block the loading of the page containing the shared more releavent information. For a newly developed website, using the above pattern is not so hard. Changing in an existing application is a different story. But the dramatic speed improvment this approach introduces should make it an option worth investigation.