The net result is to push TTI in this trace back nearly 4 full seconds: https://www.webpagetest.org/video/compare.php?tests=180912_6Q_5fd08e0ef64071de6f3cd266c36a3cac-r:1-c:0 …
-
Show this thread
-
There's a lot going on deeper in this app, it seems: https://github.com/department-of-veterans-affairs/vets-website/tree/master/content/pages … But why is the front-page paying for that? Why are our vets and their loved ones being slowed down in accessing essential services this way?
3 replies 0 retweets 6 likesShow this thread -
If there's something that *doesn't* need React, it's a drop-down menu. The sport of pure-CSS drop-downs was won more than a decade ago. There's no excuse.
5 replies 4 retweets 34 likesShow this thread -
Replying to @slightlylate
If I look at the source (in Sources pane) then what I'm seeing seems related to authentication, forms, making claims, etc. So if anything I think the goal was to make the logged-in experience have less latency from page reloads. Of course should’ve been code split from main page.
1 reply 0 retweets 1 like -
Replying to @dan_abramov
"less latency from page reloads" would be preloading cacheable assets at low priority (e.g., a <link rel="preload"> or a SW install phase), not running code on pages that don't use them.
1 reply 0 retweets 1 like -
Replying to @slightlylate
Would your experience of using Twitter improve if Twitter reloaded the page on every click? That seems to be your suggestion. I understand you re: static pages not needing React perfectly well. I agree with it. But clearly the developers didn’t use React “for a dropdown”.
2 replies 0 retweets 3 likes -
Replying to @dan_abramov @slightlylate
My point is that React was used for a dynamic part that seems to appear when you sign in. It would be better to not load that part until you actually do — and there’s nothing stopping them from implementing this with React.
1 reply 0 retweets 3 likes -
Replying to @dan_abramov @slightlylate
I think it’s a bit disingenuous to claim React makes the overall experience worse in this case since we don’t actually know what the dynamic part is like. It’s quite likely that slower initial load might be worth the wins in interaction latency _for dynamic parts_. Not home page.
1 reply 0 retweets 3 likes -
Replying to @dan_abramov
It's not React per-sae, it's *cultural* React (and other frameworks) that leave developers like this drowning in a sea of incidental complexity without the tools they need to manage the responsibilities they've (often unknowingly) bitten off by taking the reigns with JS.
2 replies 0 retweets 2 likes -
Replying to @slightlylate
Does using e.g. Polymer absolve you from responsibility not to ship the logged-in section application code on the main logged-out page?
1 reply 0 retweets 0 likes
Of course not. And I never tell anyone to use Polymer raw. I recommend systems that come with structure: Polymer PWA Starter Kit (not Polymer), Sapper (not Svelte), Next.js (not React), Preact CLI (not Preact).
-
-
Replying to @slightlylate @dan_abramov
CRA isn't on that list because it leaves users without structure or guard rails.
0 replies 0 retweets 1 likeThanks. 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.