Hacker News Reader

Comment by moxiemk1 | Hacker News Reader

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?

View on HN

If 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.

Honestly 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. :)

The 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.

Parsing 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.

I 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'?)

Reply on news.ycombinator.com