2

I'm wondering why HTTP servers do not pack a webpage request to a single file, which would then be read by the browser?

As far as I know, the amount of requests made for each webpage (CSS/JSS/images + HTML output) combined makes loading a webpage slower and also puts load on the webserver. Is there a webserver that packs all content (or as much as possible) and send it to the client?

So to illustrate my question:

Normal situation widgets.js widgets.css picture1.png picture2.png widgets.html

Pack situation

widgets.pck

Ofcourse it would give a little overhead at first, but with smart caching I'd say some improvements should be possible?

JanWillem
  • 123

5 Answers5

8

If all the objects on one particular page were served by the same server, I suppose that would be possible. In the majority of cases, though (especially with large multi-million user websites), that is not the case. Many different servers are involved with serving different parts of each page and if you required one "front end" server to gather all the resources, package them, and send them along, performance would be drastically worse than they way things work now where the browser is in charge of fetching all the page resources.

EEAA
  • 109,904
5

It is actually possible:

The advantage of having separate resources is that they are cached separately by various parts of the chain web application to web browser: - caching at file system level on the web site - separate sites for static files (images, JS, etc.) - caching and distribution network (like Akamai) - caching on the web browser.

So instead of invalidating the cache for entire page because you have added a comma, the browser will reload only the HTML page.

Also do not forget that most of the web sites and browsers are using HTTP/1.1 with KeepAlive on. This means that the objects from the same web site will get loaded on the same TCP connection.

Mircea Vutcovici
  • 18,319
3

The standard techniques for reducing number of request are:

  • putting all of JS code in one file (and minimizing it);
  • putting all of CSS code in one file (and minimizing it);
  • putting all of small, reusable images into one sprite;

However, putting it all that as inline in HTML would be impractical. JS/CSS/sprites are reusable throughout the site and they will stay in the browser's cache when you're requesting another page.

btw. I'd recommend you a book on the subject:

Community
  • 1
vartec
  • 6,237
1

Answers from webservers do not get packed into an archive, but two things do happen

  1. http keepalives which allow multiple objects to be served over one http connections (KeepAlive in Apache config terms). This only works on objects which have a known size (so the server can tell the client where the end of the current object is, which excludes dynamic objects).
  2. compression of responses (Apache module mod_deflate) negotiated between server and client

I think those two together do about the same as you suggest, but all based on negotiating between client and server about capabilities and wishes.

Koos van den Hout
  • 1,096
1

As others have mentioned, the current HTTP protocol provides limited support for this.

There's the DATA URI scheme that allows you to encode binary objects like images into base64 and inline them, effectively combining the HTML and object into one file. This reduces cache-ability but can still be worthwhile for small objects by reducing the number of short-lived connections and by reducing the transfer of uncompressed headers. Google's mod_pagespeed Apache extension performs this trick, amongst others, automatically for objects of 2k and less. See http://code.google.com/intl/nl/speed/page-speed/docs/filter-image-optimize.html

HTTP Pipelining/keepalives are useful but, as Koos van den Hout mentions, only work on objects with known size. Furthermore, pipelining and gzip compression do nothing about the uncompressed transfer of headers and cookies.

An interesting development is Google's research project called SPDY, which does almost what you suggest. Among others, it interleaves multiple HTTP requests over a single TCP connection, interleaving and prioritizing the resources. It also compresses the entire stream , including headers and cookies. Tests have shown around 50% reduction in page load times, so I'd definitely keep an eye on this project.

Google's Chrome browser is already using the SPDY protocol when communicating with Google sites like Gmail and Search. You can find some internal diagnostics by entering about:net-internals in the location bar.

Martijn Heemels
  • 7,878