Re: header vs h1 from the perspective of bytes... I really don't care about the number of bytes of HTML.
The HTML is gzip'd and if you understand the compression algorithm you'll know that every instance of is no larger than the same number of instances of
... gzip will replace all instances of either with a token. So for delivery it makes no difference at all. For the browser to parse it similarly makes no difference (complexity of the parse tree does, but that's to do with nesting and not the size of the tag name).
I think it's a false economy to prematurely optimise out every last byte. And I believe that there is a benefit to having HTML5 native tags in that currently Google appears to be giving SEO credit to sites that are implementing native HTML5 and using HTML5 tags. This is probably based on some calculation on their part that sites that are investing in HTML5 are fast moving adopters and it reflects an investment of some kind that implies a good site. Google have tons of such criteria, speed of server responsiveness is another, as is the use of microdata formats (rather than RDF).
This all means that I see no technical advantage in optimising the number of bytes of HTML, and I see a potential SEO advantage in not doing so.
The only place I care about number of bytes is in the HTTP and TCP headers. Those are uncompressed and don't benefit from gzip. So you'll see on the new platform (due about 2 months after the new design) that cookies will be stripped from all image requests and things like that. I'm going to apply optimisation where it matters. In the HTML it doesn't matter.
The only optimisation to the HTML that will happen is white-space and comment stripping. The template system inserts a ton of white-space which as you can see on LFGSS I nuke. The new theme will run on LFGSS and so will also benefit from white-space nuking.
Re: blog. Go for it.
Re: header vs h1 from the perspective of bytes... I really don't care about the number of bytes of HTML.
The HTML is gzip'd and if you understand the compression algorithm you'll know that every instance of is no larger than the same number of instances of
... gzip will replace all instances of either with a token. So for delivery it makes no difference at all. For the browser to parse it similarly makes no difference (complexity of the parse tree does, but that's to do with nesting and not the size of the tag name).
I think it's a false economy to prematurely optimise out every last byte. And I believe that there is a benefit to having HTML5 native tags in that currently Google appears to be giving SEO credit to sites that are implementing native HTML5 and using HTML5 tags. This is probably based on some calculation on their part that sites that are investing in HTML5 are fast moving adopters and it reflects an investment of some kind that implies a good site. Google have tons of such criteria, speed of server responsiveness is another, as is the use of microdata formats (rather than RDF).
This all means that I see no technical advantage in optimising the number of bytes of HTML, and I see a potential SEO advantage in not doing so.
The only place I care about number of bytes is in the HTTP and TCP headers. Those are uncompressed and don't benefit from gzip. So you'll see on the new platform (due about 2 months after the new design) that cookies will be stripped from all image requests and things like that. I'm going to apply optimisation where it matters. In the HTML it doesn't matter.
The only optimisation to the HTML that will happen is white-space and comment stripping. The template system inserts a ton of white-space which as you can see on LFGSS I nuke. The new theme will run on LFGSS and so will also benefit from white-space nuking.