Recently I’ve been following Google’s “Lets make the web faster” initiative. Speed is addictive. (Not the drug). Imagine browsing the web and having a feeling that you’ve downloaded the whole web. Yep! that’s a good dream to achieve. Below is a list of ideas, I think could make the web faster.
Compiled & Compressed Web Languages
Now I’ll borrow a few ideas from how flash movies are represented at bytecode. First the different types of objects are represented into tags, each tag is tries to parse into the object model by reading the appropriate bytes e.g first two bytes represent propertyX , then next two bytes represent property Y. In this way it doesn’t have to property names. With tags SWF’s are extendible. Finally the whole swf is zlib compressed making it very tiny. Apart from image heavy adverts, flash designers who use vectors and code heavily in their swf’s can produce amazing content at almost minute sizes.
Comparatively even if you try to do the same thing with SVG and javascript, even with gzip compression you still get higher file sizes. Google’s SPDY (pronounced Speedy) proposes to transfer anything that’s text by gzip compressing it. My proposal is rather than just treating HTML, JS, CSS as text, treat them as a separate language. i.e After the browser parses HTML/XML , JS, CSS. The languages represent themselves in an Abstract Syntax Tree (AST), The AST has nodes to hold specific types of data (e.g nodes, attributes, childs). Now if there is a standard for the abstract syntax tree, the Node Types could be just represented as Integers/Shorts, and the the AST would transfer data without its keys, as the browser can get the tree back by looking up the Node Structures from a decided standard. The binary AST could then be further gzip compressed. This would have several advantages. In essence what I am really talking about is how SWF Bytecode is represented. Moreover Action Messaging Format (AMF3) is a binary protocol designed to send large amounts of data back and forth from server to client. There are some very interesting ideas to borrow from AMF. I will see if I can do a proof of concept of how much further compression I can get on HTML, XML,JSON, CSS, JS over a binary compressed AST protocol compared to just plain text. I am expecting to acheive more than 50% (Lets see how that goes). Below are some advantages of using my above proposed format.
- The browser wouldn’t have to parse HTML,XML,JS,CSS like text, it would rather parse them directly as an AST, This would make rendering a bit quicker, as the browser can eliminate the parsing step.
- Developers can still have Extended Nodes, which would allow developers to extend the tree with their own structures.
- You binary format can still be converted back to its original text. It would still miss the extra spaces, comments e.t.c 98% of the web pages a normal user views, how many times do they check out the source. Speed is more important here.
- Better compression, meaning better speeds.
Fragment Caching
Rather than just gzip compressing a page. It is quite often that a HTML page is just a template with some data changing. If the templates can be cached independently of the data, It would speed up load times as the browser would only need to load new data. Not just templates but sometimes headers/footers/menu/sidebars are same over and over again in different pages of the same websites. Caching them would mean less data sent.
Evolved Javascript
Javascript currently is an untyped functional language. This has its advantages but when developing large applications it gets in the way. There is no support for Classes, Interfaces and typed objects. Using a typed language lets the IDE help the developer write better faster code, It lets the compiler add better optimsations. Mozilla is already working on an ECMAScript 6 implementation. I am really excited to see how it goes. Flash transitioning from ECMAScript 2 (AS2) to ECMAScript 3 (AS3) added alot of features and made it possible to write Flex SDK as we know it. A powerful language is a building block for a powerful Web.