4 ms·

> This simply should be a build step This is a great point, but when I think of build steps, I think of something like minifying which comes with a performance

> This simply should be a build step This is a great point, but when I think of build steps, I think of something like minifying which comes with a performance gain. I'm not sure I see what the obvious gain to omitting optional tags in the way Google suggests is. Edit: To clarify, I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags.

sotojuan 10y ago
Less HTML to load? Probably makes no difference in most cases, but it is less to load. Many React/Webpack flows do something like this (minify or use a barebones template HTML).
- bpicolo 10y ago
  Seems like something you can add a build step for though. Less human overhead
  - sotojuan 10y ago
    Sorry I wasn't very clear, that's what I meant by "React/Webpack" flow! See: https://github.com/ampedandwired/html-webpack-plugin https://github.com/ampedandwired/html-webpack-plugin
rtpg 10y ago
file size? It's not much, but it would still strip some stuff. I'm still bitter that HTML/XML works based off of explicit closing tags (where you can mistakenly close the wrong tag) instead of something like braces.
- TheRealPomax 10y ago
  Use a build tool (which you should be doing anyway if you hand-write any markup, because you need to validate it) and make it rewrite </> to the relevant closing tag, if necessary... problem solved? (and yes, you'd be free to even leave </> off in many, many places: https://www.w3.org/TR/html5/syntax.html#optional-tags https://www.w3.org/TR/html5/syntax.html#optional-tags). Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.
  - lgamero 10y ago
    After using pug, I don't think I can go back to plain HTML. I didn't know how much i hated closing tags.
a3n 10y ago
Maybe it reduces the load on Google's crawls of the web.
jacobevelyn 10y ago
How is a build step that turns your HTML into a smaller amount of HTML with the exact same behavior (by removing optional tags) different from a "minification" step that turns your HTML or JS into a smaller amount of HTML/JS with the exact same behavior? This is minification, isn't it?
- tedmiston 10y ago
  Updated to clarify my comment as a reference to browser performance not file size.
  - the_duke 10y ago
    Smaller file size -> faster loading (in theory... if gzipped, it's probably redundant). Possibly faster parsing, because the parser has less HTML so go through. (also probably not valid, because I'd be pretty sure that reading a string from memory is not the bottleneck in parsing, compared to logic, memory allocations, etc). It could make a difference for Googles server infrastructure though. If they have to download a tiny bit less, and save a tiny bit on CPU cycles and memory for each page, , it might still lead to considerably savings.
nevir 10y ago
> I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags. The motivation behind this style is not browser parsing perf - it's network perf. The smaller your HTTP response, the fewer packets (and round trips) required to transmit it.
- h1d 10y ago
  If you would gzip your output like you should, how much does that even buy? There's usually something better to use your time for instead of trying to shave 500 bytes out of your page.
  - TheRealPomax 10y ago
    it's not a competition, though. If there's something better to do, also do that. However, that does still leave the question of how many bytes are actually saved in transport, especially with gzipping. The benefit here is absolutely not individual developers or even individual sites, but the data transfered by entire data centers over the course of a day, week, month etc. If this recommendation can bring down the total byte transmission for "the web" by 0.001% for instance, that's still a boatload of bytes that don't bog down the network anymore.
    - Dylan16807 10y ago
      When you're looking at fractions of a percent, remember to consider other options. Set up brotli, for example. Or redesign your site to have a leaner layout. You might not ever reach the efficiency level where optimizing optional tags is the best use of dev time. And the overhead of tracking which tags are optional in which circumstances is not particularly small. Consider that the extra complexity could impede more optimizations in the future, especially now that your markup requires a more complex parser than it could have needed.
    - the_duke 10y ago
      Have you looked at the size of Youtube and Netflix videos? According to this study [1], 70% of web traffic is video streaming. Only 8% are web browsing (which might include images, because they are not mentioned anywhere else - didn't find any info on that). This is not going to make any difference.
bcoates 10y ago
The double negative phrasing Google and the spec uses makes it sound weirder than it is. You could phrase it as "only use tags that are needed for the document to be parsed correctly" which makes explicitly including an <html> tag with no attributes or a information-free stack of closing tags seem like a strange thing to do if it wasn't tradition.

sotojuan 10y ago

Less HTML to load? Probably makes no difference in most cases, but it is less to load. Many React/Webpack flows do something like this (minify or use a barebones template HTML).

bpicolo 10y ago
Seems like something you can add a build step for though. Less human overhead
- sotojuan 10y ago
  Sorry I wasn't very clear, that's what I meant by "React/Webpack" flow! See: https://github.com/ampedandwired/html-webpack-plugin https://github.com/ampedandwired/html-webpack-plugin

rtpg 10y ago

file size? It's not much, but it would still strip some stuff. I'm still bitter that HTML/XML works based off of explicit closing tags (where you can mistakenly close the wrong tag) instead of something like braces.

TheRealPomax 10y ago
Use a build tool (which you should be doing anyway if you hand-write any markup, because you need to validate it) and make it rewrite </> to the relevant closing tag, if necessary... problem solved? (and yes, you'd be free to even leave </> off in many, many places: https://www.w3.org/TR/html5/syntax.html#optional-tags https://www.w3.org/TR/html5/syntax.html#optional-tags). Alternatively, don't use HTML at all. Use pug (formerly "jade") or something and now you're free from all those inconvenient angle brackets.
- lgamero 10y ago
  After using pug, I don't think I can go back to plain HTML. I didn't know how much i hated closing tags.

a3n 10y ago

Maybe it reduces the load on Google's crawls of the web.

jacobevelyn 10y ago

How is a build step that turns your HTML into a smaller amount of HTML with the exact same behavior (by removing optional tags) different from a "minification" step that turns your HTML or JS into a smaller amount of HTML/JS with the exact same behavior? This is minification, isn't it?

tedmiston 10y ago
Updated to clarify my comment as a reference to browser performance not file size.
- the_duke 10y ago
  Smaller file size -> faster loading (in theory... if gzipped, it's probably redundant). Possibly faster parsing, because the parser has less HTML so go through. (also probably not valid, because I'd be pretty sure that reading a string from memory is not the bottleneck in parsing, compared to logic, memory allocations, etc). It could make a difference for Googles server infrastructure though. If they have to download a tiny bit less, and save a tiny bit on CPU cycles and memory for each page, , it might still lead to considerably savings.

nevir 10y ago

> I'm wondering if there's some performance gain by the browser not having to parse the implicit optional tags. The motivation behind this style is not browser parsing perf - it's network perf. The smaller your HTTP response, the fewer packets (and round trips) required to transmit it.

h1d 10y ago
If you would gzip your output like you should, how much does that even buy? There's usually something better to use your time for instead of trying to shave 500 bytes out of your page.
- TheRealPomax 10y ago
  it's not a competition, though. If there's something better to do, also do that. However, that does still leave the question of how many bytes are actually saved in transport, especially with gzipping. The benefit here is absolutely not individual developers or even individual sites, but the data transfered by entire data centers over the course of a day, week, month etc. If this recommendation can bring down the total byte transmission for "the web" by 0.001% for instance, that's still a boatload of bytes that don't bog down the network anymore.
  - Dylan16807 10y ago
    When you're looking at fractions of a percent, remember to consider other options. Set up brotli, for example. Or redesign your site to have a leaner layout. You might not ever reach the efficiency level where optimizing optional tags is the best use of dev time. And the overhead of tracking which tags are optional in which circumstances is not particularly small. Consider that the extra complexity could impede more optimizations in the future, especially now that your markup requires a more complex parser than it could have needed.
  - the_duke 10y ago
    Have you looked at the size of Youtube and Netflix videos? According to this study [1], 70% of web traffic is video streaming. Only 8% are web browsing (which might include images, because they are not mentioned anywhere else - didn't find any info on that). This is not going to make any difference.

bcoates 10y ago

The double negative phrasing Google and the spec uses makes it sound weirder than it is. You could phrase it as "only use tags that are needed for the document to be parsed correctly" which makes explicitly including an <html> tag with no attributes or a information-free stack of closing tags seem like a strange thing to do if it wasn't tradition.