We are the Website Speed Experts!

01274 985905

Delta Compression – What Is It & How Can It Help?

Posted on March 8th, 2014 by

Delta compression is a promising new technique that is, to my knowledge, something that is yet to be embraced across the modern web and will make general web browsing – when using the same site – a much more responsive and pleasurable experience.

What is it?

Delta compression, or delta encoding as it also known, works by only sending what has changed since the last transmission of data. On the web, this would typically be web pages.

It is an age old technique that has been used in the past decade or so in video compression to save hundreds of bytes by only describing what has actually changed from frame to frame whilst omitting, or leaving out, anything that has not changed since the last “frame.” As an example, the background of video may not change very often and so is only really “encoded” once and only subsequent changes to that background are “encoded” in future frames of the video.

As an example of this technique that can be applied to the web, suppose you had this rather basic web page serving as your home page:

<title>Home Page</title>
<link rel="stylesheet" href="/css/styles.css" />
<h1>Welcome to our Home Page</h1>
<p>Some example content for the home page! </p>
<p><a href="second-page.html">View our second page</a>.</p>

As you can see, it is fairly short and sweet web page (if rather simple!). If delta compression was enabled and working on the world wide web and the user clicked on the link in the second set of P tags, they could, receive the following from the server (or something to the effect):

Line 3: <title>Second Page</title>
Line 7: <h1>Second Page</h1>
Line 8: <p>Some new content for you to read!</p>
Line 9: <p><a href="third-page.html">View our third page</a>.</p>

As you can see, the server would send back just the alterations – in this case, which line numbers are changed and their new contents, allowing the web browser to create the second page based on the information is already has (the first page) and the updated info above.

Obviously, this is a rather simplified example, but as you can see, it would be much quicker to just send the updates for the first page than it would be to send the entire second page with all the additional markup.


Widespread use of delta compression on the web should see the following benefits for everyone using the world wide web:

  • Increase in speed and responsiveness for web pages on the second and subsequent visits to different web pages on the same website (or the same web pages if they change frequently)
  • Decrease in overall internet traffic as subsequent requests are smaller and much more self-contained, meaning less bandwidth overall is used for subsequent visits


Obviously, like anything in life, there are draw backs to Delta Compression, which are:

  • It takes time to generate the differences in the two files – not only do you have to know what your about to send, but also what you have previously sent to the user – especially difficult if your content is dynamically generated – do you cache the previous page and if so, how long do you keep it for? Or do you simply serve static content and use delta compression on those pages? Or do you go the long winded route of re-generating the first page as well as the second and then calculating the differences?
  • Sometimes, it may just be quicker and less “labour” intensive (for your web server that is!) to just generate and serve a second page without worrying about delta compression – particularly if the second or further pages are significantly different to the earlier versions and your end client is short on computing power
  • Delta compression, to my knowledge, although working in a few technical examples, hasn’t hit mainstream server application vendors (at the time of writing this article) and browser support for it rather limited (I may be completely wrong however, just hit me up in the comments below if I am!). There are few recommendations floating around although I haven’t really found anything on them to say that they are in effect or will be likely to be brought into effect any time soon. You can find more about them by reading up on "RFC 3229" (which seems to be the most fully fleshed out specification describing how it could be worked into browsers
  • Delta compression shifts some of the computing burden to the end users client as they have to update the current page with the new information.

It is already being used, kind of!

To an extent, this is partially true for those applications that make use of AJAX techniques to update parts of the page. AJAX can be used to make pages which submit a small request to the origin server which then returns a small subset of data for the browser’s Javascript engine to interpret and then update the page accordingly based on what is returned.

Although such web applications are relatively few and far between in general, leveraging AJAX like this (possibly even using it to create the effect of delta encoding – where the web server returns only that which has changed between "state" changes). Using AJAX this way, theoretically, means that delta compression can actually be used meaningfully on the open web without requiring any updated browsers or server changes (apart from actual code changes) that could be used in modern web browsers now – albeit in a more flexible and case dependent type.

A Working Example of Delta Compression (using AJAX)

With the state of play as it currently stands, I’ve come up with an alternative solution that could work for now until such time that it becomes practical for both browser vendors and server software to provide adequate, widespread delta compression in the vast majority of browsers.

Delta encoding could be as simple as creating a basic template frame work like this:

<title>Home Page</title>
<link rel="stylesheet" href="/css/styles.css" />
<h1 id="title">Welcome to our Home Page</h1>
<div id="content">
    <p>Some example content for the home page! </p>
    <p><a href="second-page.html">View our second page</a>.</p>
<script type="text/javascript" src="jQuery.js"></script>
<script type="text/javascript" src="change_page.js"></script>

You will notice that I have given the title an ID attribute and wrapped the "content" area in a DIV element with an ID and I have included a Script element (which loads change_page.js). The two Div elements will be used to contain the information returned from the server when it is returned.

The contents of the change_page.js would be:

$( document ).ready(function() {
    //Bind this function to all the links
    $('a').bind( 'click', function() {
        //Get the link HREF
        h = $(this).attr('href');
        //Get the page (needs to be specially formatted
        $.get( h, function( data ) {
            //gets the title that is encased in the title tag
            title = getTags(data, 'title');
            //Same for the content (in the content tag)
            content = getTags(data, 'content');

            //Update the page title
            document.title = title;

            //Update the page itself
        //"De-activate" the link
        return false;


function getTags(str,n) {
    //helper function to handle get all the contents of a particular tag
//Init the ret variable here so we have something to return
    var ret = '';
    //Get the contents here...
    if (str.indexOf('<' + n + '>') != -1) ret = str.substring(str.indexOf('<' + n + '>')+2+n.length, str.indexOf('</' + n + '>'));
    //Return the contents
    return ret;
The actual response from the server should be something along these lines to work properly with the JS above: <title>Second Page</title> <content> <p>Some new content for you to read!</p> <p><a href="third-page.html">View our third page</a>.</p> </content>

This script basically hooks the anchor tags with a JS event that makes a GET request to the server rather than making a full page request – the server would then return what has changed and the JS would change the page accordingly.


As you can this, this is rather simplistic example that should degrade nicely in those few browsers that lack Javascript (or have it disabled) – since the actual links will still continue to function as they would have done without Javascript turned on.

However, if you were to use this example in your own site, please bear in mind that it will break the Back button if used "as is" and you will have to create some sort of work around yourself. It will also make the pages “unbookmarkable” in it’s present form – I may one day update it to make it possible to do such things with the above code, but it is merely there to provide you with a starting point for your own project.

The extra work to get the above example to work with both histories and making it bookmarkable would also mean that unless you plan for it in the early stages of development, your going to have to heavily modify your CMS (if you are using one) to determine which request is being made by the client – a full normal page or the delta-compressed version of the same web page – although this is fairly easy in theory – just modify your code generating the web pages as well the Javascript code above example to append "?delta=true" or something to that effect to the end of the URI being fetched by the script and then get your server software to search for that particular end tag and serve up the page appropriately.

So with that in mind, I will leave it there! If you have any comments or questions, please let us know in the comments.

Like our articles? Like us on Facebook or Tweet about us to spread the word!
About the Author
Stephen Bailey has a passion for making websites fast and believes that the web should be faster for everyone. He is a freelance web designer & developer of 5 years experience in the trade and has helped to run and build several online communities and helped them grow and flourish.
Visit Stephen Bailey's Google+ page.


There are no comments currently for this post!

Leave a Reply

Your email address will not be published. Required fields are marked *