8  Minified

Minifying is the reducing of unnecessary information to minimise transmission and browser-processing times.

The web is largely text that is interpreted when needed. All text that is not actually required is best not transmitted so it does not occupy data lines nor require time for browsers to parse it just to ignore it. This is minifying and can be done in many ways.

HTML, CSS and JavaScript all live in text files, and usually include comments that help the developers understand and debug them. Developers also add in a lot of spaces and other whitespace to make it easier for them to read the content. All these are absolutely unnecessary for the browser's job, so do not need to be transmitted to it. These are usually filtered out, or should be.

The recommended programming practice is to use long descriptive names. Ideally, these should be reduced to minimal sizes before transmission, though while this is common for JavaScript, CSS is often left with very long class names, such as one with 114 characters in the YouTube home page. The problem with having separate minified files is that names in them are usually quite different from the source files, making it hard to reconcile runtime errors back to the original code. When an error indicates the problem code, I can just copy the code and search for that exact text in the source.

So, instead of having a myriad steps on the round-trip of debugging, I just learnt to use very short names, document them in comments which are stripped out anyway, and just not put in the whitespace to begin with. Having too many steps is creating more opportunities for errors. However, I do have the advantage that I do not have a team that would have to learn my way of doing things, or reach a compromise with, both of which would likely result in more errors being made.

The next step is only requiring what's needed for the type of page. Commonly, CSS and JavaScript are split into multiple files and only what is required is loaded, though pages used for multiple views end up having all the files regardless of whether a particular view needs it. Just have to use the browser developer tools to look at Google's very plain home page to see that there is a lot loaded that is not initially used. While they may be cached, they still require parsing with each request.

One problem with separate files for CSS and JavaScript from the HTML is that delays in those files reaching the browser can result in unformatted pages being shown briefly before those files reach the browser. The product instead loads these as part of the page, bypassing the non-formatting, but also allowing hashing of the CSS and JavaScript to prevent many attacks.

Many pages share much of these files in common. Typically, that is handled by having lots of files where each covers some common functionality while others cover unique functionality. While that arrangement works well with teams that look after the files they are responsible for, it would be too confusing for me to keep jumping around between them. I chose to use a master file for each type of content, like CSS, JavaScript, PHP or XSL, and then use specially-formatted comment lines with regular expressions that signified the page types each block was to be used with.

This allows me to have an overview of all the content while micromanaging where each block is used, down to individual lines. A JavaScript file then processes all the files, including calling VB functions in the Excel file, by splitting them up by the regular expressions, then filtering out comments, indents and line feeds. This is like conditional compilation in that it allows customisation of content and is done offline from runtime, streamlining request time processing and performance. These processed files are then what is included in a version of the product.