Considering the Tradeoffs in Page Size Optimization
Ben Halpern Sep 19, 2016
Google's style guide suggests omitting optional tags, such as
<body> and closing tags like
For file size optimization and scannability purposes, consider omitting optional tags. The HTML5 specification defines what tags can be omitted.
(This approach may require a grace period to be established as a wider guideline as it’s significantly different from what web developers are typically taught. For consistency and simplicity reasons it’s best served omitting all optional tags, not just a selection.)
This is a surprising suggestion that many developers disagree with. This is a radical approach with a number of potential drawbacks. Here are a few:
- Different parsing or scraping scenarios, besides the browsers, not known or accounted for.
- Onboarding new developers. One more thing to remember.
- Code beauty/readability.
- Unnecessary optimization.
These points can be argued on either side, and I think people will have a tendency to inject their personal taste or bias on all of them. But it is that last point, "unnecessary optimization", I want to address. Introducing potential complication in the name of saving a few bytes in the context of dozens or hundreds of kilobytes sent over the wire seems completely irrational. It is. But that does not mean this tactic should never be employed. There are a lot of web request scenarios where the math works out differently.
Not every instance of HTML page is serving the same purpose. If I am running a client-side application which relies on rich interaction, I am likely doing most of the rendering on the client. In many of these scenarios, initial server-side rendering is superfluous and the HTML sent on initial load is mostly just a shell designed for providing the basic document object model for the client code to operate on. In this circumstance, which is quite common, it makes sense to look at ways to trim every unnecessary byte as a one-time optimization. If 30% of the bytes needed to be sent over the wire can be left out of the trip, we should try to make that optimization. If you are rendering a view from the server, and these optimizations would only save maybe 3% of the load size, while also introducing way more potential failure points for different parsing environments, it is the wrong choice.
This application also commonly makes an asynchronous server request to answer the question "Is anyone logged in?". With no other information being requested, it made sense to strip out the entire body of the response and all superfluous header items that can be removed. The current request returns as few as 341 bytes of data and I believe this can be improved even more in the future. It made sense to make this one-time optimization.
It comes down to this: Don't be penny wise and pound foolish.