Site improvements - reducing dependencies

[subscribe] Recent blog entries

• Simple prototypal inheritance new!
• Adventures in Rhino - setters and getters
• Site improvements - fighting with Disqus
• JavaScript task chaining
• JavaScript string building benchmarks
• Efficient JavaScript string building
• Alternative JavaScript worker thread API
• Implementing JavaScript worker threads
• Thread safe DOM manipulation
• Site improvements - CSS sprites
• Trephine worker threads made easy
• Pitfalls of multithreaded browser development
• Site improvements - reducing dependencies
• The unsplittability of XML

Live Demos

• Executing arbitrary script
• Shell commands
• File browser
• Excel data extractor new!
• Persistent client side database
• Groovy demo
• JavaFX demo
• Ruby demo

Site improvements - reducing dependencies

In an effort to serve you better, the trephine.org site has undergone some size-reduction surgery today. I have reduced the total number of requests necessary to load a page by quite a bit. Whereas previously a page such as this would require 44 elements (including all CSS, JavaScript and HTML), it now takes about 22.

The primary effect was reducing the number of CSS requests by combining files, but a few JavaScript files have also been shuffled around. If you notice anything funny about the site, please hard-refresh (usually Ctrl+F5 in Windows/*nix and Cmd+F5 on Mac OS).

Many of the requests which have been eliminated would previously have been served by PHP accessing a Database cache, so roundtrips to the DB have also been reduced.

In the early days of the web, bandwidth was scarce. Many web users were on dialup modems, and so the canonical advice to webmasters was to break a page up so that the heavy lifting of downloading all the content could be spread out over a series of requests. Sometimes this was referred to as amortization. An amortized site would break up a big image into a set of small images and load them into a table acting as a grid to lay everything out.

Times have changed, and now most web users (especially visitors to technical sites such as this) have more than sufficient bandwidth to load a given page quickly. The limiting factor is now latency - exactly the opposite of what the old advice optimized for. Now the right thing to do to make a site perform quickly is to cram everything together into the smallest number of bundles so that the irreducible round-trip time from browser to server has the smallest possible effect.

Combining and minimizing CSS and JavaScript are some of the techniques used to make sites inherently faster. Other techniques include lazy-loading scripts, distributing static content and pushing images into sprite maps. As I continue to trim and optimize trephine.org in an attempt to make it as fast as possible, I'll report more on these topics.

Anyway, I apologize to those who came here looking for another JavaScript/trephine revelation today. Sometimes you've just gotta clean house once in a while.