Skip to content
This repository has been archived by the owner on Oct 1, 2021. It is now read-only.

template vs div #92

Closed
wants to merge 6 commits into from
Closed

template vs div #92

wants to merge 6 commits into from

Conversation

valdrinkoshi
Copy link
Collaborator

@valdrinkoshi valdrinkoshi commented Jun 7, 2018 •
edited
Loading

Testing out some ideas for indexability/find-in-page, in particular, how much does it take to append the whole HTML Spec in a template vs a div?

Here the averages of 5 runs on Chrome Canary v69.0.3451.0.

  • parse time: time it takes to parse all the HTMLSpec and collect the children (done with Streams + iframe.write() + Mutation Observer on iframe's body)
  • render time: time it takes to append all the children in the container and force layout + paint
  • innerHTML time: time it takes to innerHTML all the spec as a string in the container and force layout + paint

Mac Book Pro Retina 15" 2015

parse (ms) 2135.68
container render (ms) innerHTML (ms)
template 14.50 480.46
body > template 12.50 460.48
div 21.56 611.62
body > div.hidden 83.78 649.80
body > div 3985.50 5814.36

Pixel 2 XL

parse (ms) 3007.64
container render (ms) innerHTML (ms)
template 29.30 788.08
body > template 22.72 775.14
div 42.26 896.80
body > div.hidden 177.66 994.12
body > div 6018.54 8705.92

Hauwei Y5 Lite 2017

parse (ms) 13383.66
container render (ms) innerHTML (ms)
template 142.04 3373.76
body > template 124.58 3314.48
div 190.22 3790.78
body > div.hidden 624.06 4423.18
body > div 28715.20 35877.00

@domenic @ojanvafai @graynorton FYI

@domenic
Copy link
Collaborator

domenic commented Jun 7, 2018

Hmm, it sounds like the data is getting a bit hard to interpret because of the streaming technique we are doing. That is, it isn't giving us very much insight into the cost of the DOM itself.

What about trying something different, where we read the entire spec into memory using response.text(), then append the elements into a template vs. div? No iframes involved. It might be hard because then we have to figure out element boundaries from the raw text, although I think we already have code for that...

@valdrinkoshi
Copy link
Collaborator Author

valdrinkoshi commented Jun 7, 2018 •
edited
Loading

uhm, what about getting it as a string and innerHTMLing it?
The current implementation in HTMLSpec parses the string through iframe.contentDocument.write(chunk) + MutationObserver on iframe.contentDocument.body

@domenic
Copy link
Collaborator

domenic commented Jun 7, 2018

Yeah, I guess we should check that too, although it feels like without the ability to break up the work into chunks, it'll just jank for a very long time.

@valdrinkoshi
Copy link
Collaborator Author

valdrinkoshi commented Jun 7, 2018 •
edited
Loading

I just did a test with innerHTML, here the results

container parent render time
<div> null 457.18
<template> null 370.14
<div hidden> <body> 527.42
<template> <body> 356.00
<div> <body> 5510.64

@domenic
Copy link
Collaborator

domenic commented Jun 7, 2018

Hmm, that's not so bad I think, although janking for a third of a second (on desktop, I presume) is not good and we'd want to break that up into chunks with requestIdleCallback or similar. But the total time being around that much seems promising to me?

@valdrinkoshi
Copy link
Collaborator Author

The spec time measurement shows that it takes around 1.2+ seconds to have all the spec loaded and ready, even if in chunks - the HTMLSpec class creates and attaches a hidden iframe and does write + MutationObserver for parsing.

I'm not sure what's the overhead of iframe vs div, but the fact that iframe takes care of parsing so nicely makes it worth it. Maybe with more structured data we can write a simple parser?

@domenic
Copy link
Collaborator

domenic commented Jun 7, 2018

Yeah I think we'd have more structured data in a realistic version of the spec-viewer (e.g., on a news reader site that was using this for a long article, or something). So it's not worth worrying about that part too much.

Would it be easy to get these numbers on mobile devices? Preferably both a high-end one and a low-end one, although whatever you have lying around is fine.

@valdrinkoshi
Copy link
Collaborator Author

Will have some numbers tomorrow - I got a low-end device to torture 😁

@valdrinkoshi
Copy link
Collaborator Author

Got new numbers! updated the description, PTAL!

@domenic
Copy link
Collaborator

domenic commented Feb 8, 2019

Doing some housekeeping and closing this PR; thanks so much for the very-useful measurements, which will definitely be guiding us going forward.

@domenic domenic closed this Feb 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@valdrinkoshi @domenic