3 ms·
I hope that in determining which HTML is optimal bandwidith wise, there is also some consideration of what HTML is optimal rendering wise. (obvious cost savings
by moxiemk1 16y ago
I hope that in determining which HTML is optimal bandwidith wise, there is also some consideration of what HTML is optimal rendering wise. (obvious cost savings of going hard down the bandwith optimizing aside)
Knowing how the parser treats certain constructs and deviations from the spec. probably gives us some insight into how long things will take to parse. Or is client side that much faster than waiting on normal network latency?
- yason 16y agoThe parsing time is probably negligible. I would guess that parsing HTML5 would be a few if not dozens of megabytes per second on modern hardware.
- SpikeGronim 16y agoParsing speed depends on the markup. One example is text layout, which is O(N) in the size of the text area. So 1 MB of text might be a lot slower to parse than 1 MB of no-op tags.
- Someone 16y agoI would not say text layout is done during parsing, it is done when the parse tree that parsing produced is used to produce a render tree ('execution time'?)
- antimatter15 16y agoIf you've seen Google's Chrome Fast ads where a potato rocket passes the length of a computer monitor slower than it takes to render a somewhat cluttered web page, that's loading from disk.
- jasonmoo 16y agoHonestly I was hoping this was going to be an article about optimal markup ordering and nesting for lightening quick rendering time and javascript event handling.. I'm curious if we will see actual packers that rename tags and rewrite css to drop markup size. HTML5 seems to make it easier to create your own tag soup. :)