4 ms·

> 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

by 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.
    - TheRealPomax 10y ago
      Just because the vast majority of roads are for cars doesn't mean we should therefore not try to optimize the bike and pedestrian lanes. Sure, a lot of the traffic is streamed data rather than HTML, but 30% of close to a zetabyte of data in a single day (for the internet as a whole) is still hundreds of petabytes that can be made drastically smaller. When the numbers are that large, even optimizing for something as "insignificant" as 0.01% of the traffic means 10s or even 100s of terabytes not pumped through the network every day.
      - h1d 10y ago
        You sound like you want to act for the good of the whole human beings but we have priorities over shaving the last bytes off our pages. You would have a better day to let webmasters know to use gzip if they aren't.
        TheRealPomax 10y ago
        As always: optimizations are not a matter a of "one or the other" they're about "do all of them". Make the build tool apply all optimizations and minifications, and make the client-server connection negotiate as much compression as possible. Don't stop at just gzip when further improvements are trivial (like this one).
- M2Ys4U 10y ago
  compression and encryption often don't play nice with each other. See CRIME and BREACH, for example.
DougWebb 10y ago
If your output is compressed (which it should be if you're worried about response size) then omitting end tags has much less impact, I believe. All of the tags should get compressed well because they're repeated so often, and they should be much smaller overall than your non-repetitive content.
- TheRealPomax 10y ago
  But note that on the scale of move as much data around as Google does, or even "the web as a whole", shaving even a few bytes off of every single gzip packet stream can still equate to significant network relief.
  - DougWebb 10y ago
    I suspect their advice is for their benefit, not other website devs. They can save a lot of space in their archive if everyone's pages were smaller. Nothing compared to better image compression though.
    - dgacmu 10y ago
      No - a few bytes on a web page are insignificant compared to the data volume of images and movies. This is all about getting pages to load faster on mobile.
- nevir 10y ago
  If those extra bytes drop you from two packets to one, that's a _significant_ reduction in traffic (which, IIRC, was the original rationale behind that style guide rule)
deleted 10y ago
[deleted]

by nevir 10y ago

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.
  - TheRealPomax 10y ago
    Just because the vast majority of roads are for cars doesn't mean we should therefore not try to optimize the bike and pedestrian lanes. Sure, a lot of the traffic is streamed data rather than HTML, but 30% of close to a zetabyte of data in a single day (for the internet as a whole) is still hundreds of petabytes that can be made drastically smaller. When the numbers are that large, even optimizing for something as "insignificant" as 0.01% of the traffic means 10s or even 100s of terabytes not pumped through the network every day.
    - h1d 10y ago
      You sound like you want to act for the good of the whole human beings but we have priorities over shaving the last bytes off our pages. You would have a better day to let webmasters know to use gzip if they aren't.
      - TheRealPomax 10y ago
        As always: optimizations are not a matter a of "one or the other" they're about "do all of them". Make the build tool apply all optimizations and minifications, and make the client-server connection negotiate as much compression as possible. Don't stop at just gzip when further improvements are trivial (like this one).
M2Ys4U 10y ago
compression and encryption often don't play nice with each other. See CRIME and BREACH, for example.

DougWebb 10y ago

If your output is compressed (which it should be if you're worried about response size) then omitting end tags has much less impact, I believe. All of the tags should get compressed well because they're repeated so often, and they should be much smaller overall than your non-repetitive content.

TheRealPomax 10y ago
But note that on the scale of move as much data around as Google does, or even "the web as a whole", shaving even a few bytes off of every single gzip packet stream can still equate to significant network relief.
- DougWebb 10y ago
  I suspect their advice is for their benefit, not other website devs. They can save a lot of space in their archive if everyone's pages were smaller. Nothing compared to better image compression though.
  - dgacmu 10y ago
    No - a few bytes on a web page are insignificant compared to the data volume of images and movies. This is all about getting pages to load faster on mobile.
nevir 10y ago
If those extra bytes drop you from two packets to one, that's a _significant_ reduction in traffic (which, IIRC, was the original rationale behind that style guide rule)

deleted 10y ago

[deleted]