Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add parse5-based streaming parser #2

Merged
merged 3 commits into from
Sep 28, 2017

Conversation

RReverser
Copy link
Contributor

@RReverser RReverser commented Sep 27, 2017

Played with parse5 with @inikulin to implement the streaming element PoC in userland (for now it allows moving stuff outside the context, see discussion in whatwg/html#2993 (comment)).

Gives same benefits as iframe hack, but with correct parsing directly to the target DOM (although final render is obviously slower for now than any native approach).

For now, just for the demo purposes, uses private parse5 APIs to rip parseFragment into pieces suitable for streaming.

Results from WebPagetest:

Demo page: https://rreverser.github.io/streaming-html/

Gives same benefits as iframe hack, but with correct parsing directly to the target DOM.

For now, just for the demo purposes, uses private parse5 APIs to rip parseFragment into pieces suitable for streaming.
@RReverser
Copy link
Contributor Author

RReverser commented Sep 27, 2017

Optimized the DOM adapter a bit (and already pushed). New results jump around, but it seems to be on par with the iframe hack now (WPT is here):

@jakearchibald
Copy link
Owner

This is great, thank you!

@RReverser
Copy link
Contributor Author

@jakearchibald Would it be worth to update the blog post to include benchmarks with this approach?

@RReverser
Copy link
Contributor Author

@jakearchibald Ping ^?

@jakearchibald
Copy link
Owner

Missed this sorry. Keeping the tab open, might get to it tomorrow.

@jakearchibald
Copy link
Owner

I'm struggling to recreate these results locally. The manual parse5 parser seems significantly slower running on my local machine, which is kinda what I'd expect.

Also the results would hide the download & parse overhead of the JS.

@RReverser
Copy link
Contributor Author

Also the results would hide the download & parse overhead of the JS.

Why would they? It's still part of time to first meaningful paint etc., no?

@jakearchibald
Copy link
Owner

Right, but we're comparing a 1k script to a 300k one, and the tests don't reflect that.

@jakearchibald
Copy link
Owner

(that isn't your fault, I didn't include it in the results because the script size was too small to be meaningful in the things I was originally testing)

@RReverser
Copy link
Contributor Author

Well, size-wise, sure, but then on WPT I used mobile simulation mode, so this would've been reflected on timings anyway if it would be too bad. Either way, that's obviously more of a PoC than production version, although might work fine even on real web apps when cached (thanks to bytecode caching in modern engines).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants