The "SSR is for performance" folks need to be posting traces from mid/low-end devices/networks to demonstrate that their experiences get consistently interactive fast enough to make the magic trick actually work.
-
Show this thread
-
When I look at traces, it's 99% this:pic.twitter.com/xvtI02l0FH
6 replies 6 retweets 40 likesShow this thread -
Getting a trace is super simple! 1.) go to: https://www.webpagetest.org/easy 2.) paste in URL 3.) select "Mobile - Regular 3G" 4.) click both checkboxes 5.) click "Start Test" 6.) share resulting URL
3 replies 8 retweets 38 likesShow this thread -
Replying to @slightlylate
What do you think is a good score? Here's the result for http://unsplash.com . (By sharing this I'm not implying we do this very well.) https://www.webpagetest.org/result/190620_RY_574cc1b8b8a62fca29ab24629e769129/ …
1 reply 0 retweets 0 likes -
Replying to @OliverJAsh
You should be able to get to consistently interactive on first load in less than 5 seconds on that configuration (preferably 3).
1 reply 0 retweets 1 like -
Replying to @slightlylate @OliverJAsh
If you look at the "main thread" chart at the bottom here, you see that it's currently at ~8 seconds: https://www.webpagetest.org/result/190620_RY_574cc1b8b8a62fca29ab24629e769129/1/details/#waterfall_view_step1 …
2 replies 0 retweets 1 like -
Replying to @slightlylate
Oliver Ash Retweeted Oliver Ash
This is really not good. For context, this is a SSR'd "universal" React app, with CDN HTML caching. I've been asking the React community for solutions to this problem for awhile (the very expensive hydration), because it's not just us—but still a mystery:https://twitter.com/OliverJAsh/status/1042726866770161665 …
Oliver Ash added,
Oliver Ash @OliverJAshOn Unsplash, the first client React render pegs the CPU for several seconds on avg devices—as I'm sure is the case w/ most large React apps. Unhappy about this but solutions are unclear. This idea would go some way to fixing it. Also hoping async rendering will help? https://twitter.com/philwalton/status/1042684111691771904 …1 reply 0 retweets 1 like -
Replying to @OliverJAsh
You can get a feeling for how this would be experienced on device by clicking into the "Filmstrip View", which lets you correlate the screen updates and main-thread time with network activity: https://www.webpagetest.org/video/compare.php?tests=190620_RY_574cc1b8b8a62fca29ab24629e769129-r%3A1-c%3A0&thumbSize=200&ival=100&end=full …
1 reply 0 retweets 1 like
what I see here is ~300KiB of JS in the critical path. The size of the JS means a lot of the time is just spent in downloading it, over and apart from the great deal of main-thread work happening.
-
-
Replying to @slightlylate @OliverJAsh
Sorry for the slow follow-up; I was curious to see how this would perform if you didn't load all the heavyweight JS. Still trying to extract that from WPT...not sure why it's not working for me at the moment.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.