Google's style guide suggests omitting optional tags, such as <head>, <body> and closing tags like </p>.
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 is the model with which to look at most of these sorts of optimization questions. This website recently moved away from New Relic's application monitoring solution because it necessitated an injection of a few KB of JavaScript into the page's head, proving it difficult to measure performance without effecting it using this tool. This was the right choice for this application, given some of our atypical measures taken to ensure pages are rendered as swiftly as possible. New Relic was accounting for enough of the weight of initial render that it was worth dropping the script. But if you ask me if you should do the same, my likely answer would be "Hell no". Saving bytes seemed like the right choice to make for us, at least for now. It is unlikely to be the right choice for you unless you design your HTML experience the way we did.
I am skeptical of the approach of making this optimization part of a build step as in the way JavaScript or CSS is minified and compressed. I think you run the risk of assuming the existence of a certain tag will be referenceable from JavaScript when it will not be. I would not want to deal with the class of runtime errors this could produce. This point is debatable, but in this circumstance I would rather write the markup that will run in production than compile it.
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.
Top comments (0)