(while I wait for the trace to come back, I should note that I'm tracing many of these rn, and none of them have come back anywhere *near* OK, not even on a simulated 4G link; @gatsbyjs's featured sites are a performance superfund site)
-
-
Replying to @slightlylate @matthewcp and
Actually, looking closer, it seems to *not* be a public-sector site, so I can't post trace = ( Looking for a representatitve Gatsby public-sector page now.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
Ok, this appears to be Gatsby: https://revenuedata.doi.gov Per blog post here: https://revenuedata.doi.gov/blog/homepage-revamp-part-two/ …
3 replies 0 retweets 1 like -
Replying to @slightlylate @matthewcp and
Being generous & testing on 4G: https://www.webpagetest.org/result/191017_J5_d438a3f9ef614a319b46a66ae936fb5b/ … Remember, this is govt, so 3p load should be light. My expectation for static site on this config is *easily* interactive in < 4s, and "good" is ~2s. Let's go to the tape: https://www.webpagetest.org/result/191017_J5_d438a3f9ef614a319b46a66ae936fb5b/2/details/#waterfall_view_step1 …
2 replies 0 retweets 2 likes -
Replying to @slightlylate @matthewcp and
This could have easily painted at the 1.5s mark: https://www.webpagetest.org/video/compare.php?tests=191017_J5_d438a3f9ef614a319b46a66ae936fb5b-r%3A2-c%3A0&thumbSize=200&ival=100&end=full …
1 reply 0 retweets 0 likes -
Replying to @slightlylate @matthewcp and
...but nope, we're using
@gatsbyjs, so it dutifuly created multiple 100KiB+ (compressed) JS bundles. Despite full knowledge of the app state, it didn't treat the the 576KiB/3.1MiB main page bundle as a build error: https://revenuedata.doi.gov/component---src-pages-index-js-a39b8cce9d5b75c48a87.js … /cc@addyosmani2 replies 0 retweets 6 likes -
Replying to @slightlylate @matthewcp and
This would have been a full second worse, but modern Chrome is effectively magic and moved two ~500ms parse tasks off to a background thread for the script: https://www.webpagetest.org/chrome/inspector-20190809/inspector.html?experiments=true&loadTimelineFromURL=/getTimeline.php?timeline=t:191017_J5_d438a3f9ef614a319b46a66ae936fb5b,r:2,c:0,s:1 …
1 reply 0 retweets 3 likes -
Replying to @slightlylate @matthewcp and
This is modern React (16.8.6) and modern
@gatsbyjs, and it's *not OK*.2 replies 1 retweet 12 likes -
Replying to @slightlylate @matthewcp and
Gotta dig into the sources to verify, but it appears the JSON is also creating a ridinkulous main-thread eval (multiple seconds!!!) because it's leaning on XHR and not fetch(). Everything here was preventable.
4 replies 0 retweets 5 likes -
Replying to @slightlylate @matthewcp and
Wait why the heck are they not using fetch?
1 reply 0 retweets 0 likes
Something about a double-fetch bug? IDK. Anyhow, you can always `let data = await (new Response(...)).body.json()` instead of `JSON.parse(...)`
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.