-
Notifications
You must be signed in to change notification settings - Fork 0
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
Counter argument #1
Comments
@icyJoseph Thanks for looking into this. We'll confirm your results, and also get this deployed on Vercel so we can test it with pagespeed insights to see if the conclusions are the same. If so we'll have to return to the original project (which we can't share) with the problem and produce a new hypothesis why its TBT doubled due to an app dir conversion. |
Great! Perhaps you are shipping tons of JSON data for each page. You can use
node index.js http://0.0.0.0:3000
Found client data key: 1
Found client data key: 2
Found client data key: 3
http://0.0.0.0:3000
HTML: 44.17 KB - 57.0%
JSON: 33.36 KB - 43.0%
JSON Client Data: 6.95 KB - 20.8% Now you can see your initial page load from another perspective, not only JS. More here: https://youtu.be/FfHsIio4aCU?t=1117 |
One additional thing, you could also share the pagespeed result URL, and from there we could also help each other, it even gives access to the tree view - which might be key in this case. |
Hi,
I notice the claim here is based on the
all
result on the bundle analyzer.However if we inspect the transferred JS to load the landing page:
app
pages
So what gives? well the key is the
main-cea54f6ff400d8c7
module, when is it downloaded? If we, in the app dir branch, go tolocalhost:3000/foo
, we see the 404 page, and in the downloaded assets:My conclusion is that taking the
all
value in the @next/bundle-analyzer as a total count for the transferred JS per page, is not correct. Nor is it necessarily theFilter to initial chunks > app/page
filter in the UI.The text was updated successfully, but these errors were encountered: