Beginner’s Guide to Techniques for Refreshing Web Pages: Ajax, Comet, HTML5


This article briefly discusses the technologies used in modern browsers to display web pages, and goes into a little more detail about the user experience on those web pages, in particular how we can get part of a web page to refresh automatically when data changes on a web server.

Browsers and HTML

I’m sure anyone who’s reading this page is aware that the web is based on a request and response process that returns web pages of data.  If I click on a link my browser makes a request for the web page specified in the link, the request gets routed to the appropriate server, and the server responds with a page of HTML which my browser displays.

HTML (hypertext markup language), of course, is a simple markup language that tells a browser where to put text and images on a web page using tags (e.g. <header>).  The request format is a text URL (uniform resource locator) of the kind you see all the time in your browser’s navigation bar.  Furthermore, the returned text can contain additional links that the browser will show underlined and that I can click on.

Anyone who uses the internet understands this, but the success of the web is at least in part due to the simplicity of that model.  The HTML is just text with a few special tags in angle brackets, and all a browser has to do is know how to send a request, handle the response, and then draw a screen using the HTML that’s returned.  Similarly all a web server has to do is know how to receive a request, get the right HTML text to send back, and send it.  Often web servers will simply store the text in text files on their hard drive, and just load and send the right one in response to a request depending on the text of the request.

At root it’s unbelievably simple; just look what it’s turned into.

Other Technologies Used In Web Browsers

Of course modern browsers aren’t as simple as described above and there are a number of other technologies that they understand and developers can use.

Firstly, developers want to write code, so there’s also a programming language embedded into every modern browser.  This is Javascript.

Javascript allows programmers to write little bits of code that can run when events happen in the browser.  The Javascript can manipulate what’s displayed in the browser programmatically, or can perform other actions.

For the Javascript to change what’s displayed it needs to manipulate the HTML.  Obviously this can be done by simply changing the text.  However, there’s a programmatic representation of a web page that Javascript can use to manipulate elements within it.  This format is the Document Object Model or DOM.

Another baseline technology for what gets displayed to the client is Cascading Style Sheets (CSS).  These allow a common look and feel to be applied to a group of web pages without the need for detailed coding in each page.

Drawbacks of the Basic HTML Request/Response Page-Based Model

HTML + Javascript + CSS allows us to create quite sophisticated web pages.  However, there’s one big drawback with the model as described above: to display new data we have to click on a link to request a whole new page and wait whilst it loads.

For a more sophisticated user experience there are a few things we might like to have:

  1. The ability to refresh part of a web page without reloading the entire page.  Initially this could be initiated by the user clicking a button, but we want just the relevant data to update, not the entire page.
  2. The ability to do this refresh whilst allowing the user to continue to interact with the rest of the page.  That is, the request shouldn’t block the user, it should be asynchronous.
  3. The ability to update the page when data changes on the server without the user having to refresh in any way.

1.  Refreshing Part of a Web Page

The first problem that developers tried to solve was updating part of a web page in place without reloading the entire page.  There are several ways of doing this.


However, there are some simple approaches that predate Ajax.  One is to use IFrames.  These are HTML elements within a page that can issue their own request/responses to a web site and render the results independently of the rest of the page.  They have a SRC property that can be set to a URL.  If you set the src to a different or the same URL (say on a button click) the new data will appear without a full page reload.

Many developers don’t like IFrames.  Search engines can get confused by them.  They may show scrollbars if your content doesn’t fit correctly.  Worse if your user has scrolled to the bottom of a page and then you load a new shorter page in the same frame they may be off the bottom of it.  Because of restrictions in HTML IFrames can usually only issue requests to the same site as the main site of the page they are on.  All of this means people have looked for better solutions.

Script Injection

Another approach to refreshing part of a web page is client-side script injection.  This takes advantage of the fact that Javascript code in a web page can be retrieved from a server using a URL via a src tag.

The basic approach is the same as for IFrames: we can set or reset the src of the script code, and the browser will retrieve the script from the URL and execute it.  If we send back valid Javascript that updates part of our web page, or calls a function that does, then we don’t have to refresh the entire page.

One advantage of this approach is that script tags can issue requests to any URL, not just the same site as the page they are on.  One disadvantage of this approach is that it can lead to security vulnerabilities in the code.


JSONP is just a way of using client-side script injection across domains to get data from a different website: we request the script from the different server and it returns it as the parameters of a Javascript function which immediately executes and uses the payload.

2.  Refreshing Part of a Web Page Asynchronously

Ajax (Asynchronous Javascript and XML) is probably the primary technology for this.  Ajax is actually a label applied to a way of using many of the technologies described above to allow web pages to be displayed and then be updated asynchronously without reloading the entire page.

The main distinguishing feature of Ajax is that it uses a relatively new request response mechanism.  This is called XMLHttpRequest.  When a browser makes a request using XMLHttpRequest it provides the name of a Javascript function that will be called back by the server.  This function will have access to the data sent back from the server.

The original call to the server will not block and will not reload the page.  The user can carry on interacting with the page as usual, even if the call to the server takes some time.

It is up to the callback function to make whatever changes it needs to make to the web page using the usual Javascript techniques described above.  This will typically involve updating just a part of the screen.

One thing to note here is that the data returned is just text.  It doesn’t have to be XML, in spite of the names (XMLHttpRequest, AjaX).

3.  Updating a Page Automatically when Data Changes on the Server

Ajax as described so far updates a page in place, but only in response to a request from the web page.  This means that the user has to click a button or something similar for the page to update.

Obviously there are situations where data is changing and we would like it to update on our web page without the need for the user to manually refresh.

There are quite a few ways of doing this, some of them direct extensions to the Ajax model described above:


Javascript allows us to fire events that run code in the browser at set intervals.  So a very simple approach is to automatically request a refresh of the part of the screen we are interested in updating periodically.  We can do this using the Ajax techniques above, so that the rest of the screen remains responsive.

The drawback to this is we may make requests when no data has changed, putting unnecessary load on our servers.  Also our data on the client may well be out of date at any given time if we are between polling requests.

We really want a way for our server to send data only when it’s changed, and at the moment it has changed.

Long Polling

Another approach is long polling.  Here the browser fires off a request with a long timeout and sets up a handler for the results using Ajax as before.  However, the server itself doesn’t respond until it has data that has changed, and then it sends the data in response to the original request.  The browser handles the request and immediately sets up another long timeout request for future updates.

The disadvantage of this approach is that the server has to keep the connection (a network socket) open until it has data.  In general it will have as many connections as it has clients waiting for data.  This obviously puts load on the server and the number of sockets that the server can possibly use becomes a limiting factor.  Also this is clearly a more complex solution to implement than normal (short) polling.


In streaming the client makes a request and the server responds with an open response that keeps the communication channel open and allows subsequent responses to be sent to the client.  The server may eventually time out the connection, or may keep it open indefinitely.  If the connection times out the client will have to make another request to refresh the data.  So this approach is like long polling with the client needing to make fewer requests.

One drawback of this approach is that many proxy servers buffer http responses until they are complete: that is, they won’t send on the message until they have the completion.  This means the client won’t get timely updates.  Another obvious drawback is that this is a fairly complex way of keeping data up to date.

With all of these approaches the call backs from the server tend to tie up one http communication channel.  As a result many approaches to solving the problem use (at least) two channels: one for polling or streaming to  update the data in place, and one for regular requests from the client to the server.

A number of commercial frameworks have been built using these techniques.


Comet is a name that’s been applied to the techniques described above to update a web page in place automatically when data changes on the server using a longlasting HTTP connection.

HTML 5 Web Sockets

HTML 5 web sockets are the new way to do bidirectional communication between a web page and a server.  They don’t use the old HTTP request/response at all, but instead set up one dedicated channel for communication between client and server.  This is fast, and the messages involve very little redundant header information, unlike conventional HTTP requests.

The main drawback of this new technology currently is that many browsers do not support it.  For example, it doesn’t work in the last version of Internet Explorer, IE9, although it works in IE10.



2 thoughts on “Beginner’s Guide to Techniques for Refreshing Web Pages: Ajax, Comet, HTML5

  1. Nice concise overview.
    What about SignalR (if you’re a .NET developer) it’s a specific technology I know but,
    will do Web Sockets if the browser supports it. If not it falls back to long polling

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s