Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. The web in kit form When we request a document from a web server, what we actually get is a bunch of components: images, styling instructions, javascript code and the actual content. The browser stitches all this together into something that (hopefully) matches the designer's original brief.
  2. 2. The web in kit form <ul>All of these elements have to be downloaded separately over the same connection, so the smaller they are the better: it takes less time for each piece to arrive, and we need to send less data overall (important if you are paying per-byte!) </ul>
  3. 3. The web in kit form <ul>The HTTP specification allows browsers to ask for content to be delivered by the server in different ways. The server can comply if it is able, or default to sending the content 'as-is'. One of the options is to send it 'compressed'. This means that, where it can, the server uses an algorithm to remove the 'human-readable' bits of the content before it is sent. </ul>
  4. 4. The web in kit form <ul>When the compressed content arrives, the visitor's browser uses the same algorithm to stuff it all back in again and recreate the component as it was originally. This is a trade off between sending less 'stuff' across the network and making both the server and the visitor's computer work harder. </ul>
  5. 5. The web in kit form <ul>We can't compress everything. Images, for instance, are binary data which has probably already been squeezed as much as possible. So image-heavy sites aren't going to benefit from this (though the browser should be caching these, so it's a one-time hit). </ul>
  6. 6. The web in kit form <ul>Sometimes compression works against you. For example, it's inefficient to compress lots of small files compared to one big one. Some web servers work around this by joining small files together at the point of delivery. This needs careful work on the front-end web design to work effectively, though. </ul>
  7. 7. The web in kit form <ul>Other effects can mask the benefit of compression, e.g. the time to generate a page in a dynamic application, e.g. the VITES homepage: <li>Without comp: 31.7kb size, 644ms wait, 13ms receiving
  8. 8. With comp: 8kb size, 667ms wait, 1ms receiving </li></ul>
  9. 9. The web in kit form <ul>Works better for 'static' content, e.g. MyUltralase.js <li>Without comp: 69kb, 13ms wait, 42ms receive
  10. 10. With comp: 19kb,13ms wait, 7ms receive
  11. 11. Could reduce the wait by pre-compressing static files. </li></ul>
  12. 12. In summary <ul><li>No silver bullet.
  13. 13. Biggest wins delivering static content.
  14. 14. Overall benefit depends on makeup of site.
  15. 15. Need to work on process to extract most gain. </li></ul>