chore: attempt to create a bundle analysis file

[ovflowd]

This PR attempts to add bundle analysis within the Pull Request GitHub Action. This uses https://github.com/hashicorp/nextjs-bundle-analysis

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 9, 2023 4:57pm
nodejs-org-stories	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 9, 2023 4:57pm

[github-actions]

📦 Next.js Bundle Analysis for nodejs.org

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[bmuenzenmeyer]

@ovflowd this is cool! Should we combine this with the real user metrics capabilities of Lighthouse CI? That would give us a nice automated window into measurable UX and regressions for relatively little cost (slower CI)

[bmuenzenmeyer]

small future idea inside

[ovflowd]

@ovflowd this is cool! Should we combine this with the real user metrics capabilities of Lighthouse CI? That would give us a nice automated window into measurable UX and regressions for relatively little cost (slower CI)

Sure, and that sounds awesome, but I am still determining how efficient the solution of this PR is. We would need to see an example of this running. Also, it only supports Next.js.

I'm worried about this not working or the analysis not being good enough. I've found an example of this being used: MaciejGarncarski/photo-app#38 (comment) another example, hashicorp/dev-portal#2050 (comment)

[bmuenzenmeyer]

I imagine this solution doesn't work until you have a baseline.

well, lighthouse will test the site as a user would experience it using standard web-vitals metrics. Those metrics are perhaps more valuable. Really, they ALL are valuable, as the value comes from an awareness as developers on the impact of our actions... and if we are okay with the delta's they produce.

[ovflowd]

(I wrote this before your last comment, Brian)

Also, since our pages are dynamically generated, the Markdown content of each page is not taken into consideration on the page-size. So the extra Markdown (MDX) content might add a few KB's depending of the page.

But since those are part of the content-itself, they're not part of the "bundle", as on the server-side rendering they're rendered as HTML and not part of the bundle itself.

Worth mentioning that, these static props are probably loaded within the page on pre-fetch or when the page is invoked directly (Example: https://vercel.nodejs.org/_next/data/7UowjOarLsTee3Vh3lvww/en.json?path=en)

But I wouldn't take these into consideration, to be honest.

[ovflowd]

well, lighthouse will test the site as a user would experience it using standard web-vitals metrics. Those metrics are perhaps more valuable. Really, they ALL are valuable, as the value comes from an awareness as developers on the impact of our actions... and if we are okay with the delta's they produce.

Yeah, that's what matters.

I imagine this solution doesn't work until you have a baseline.

Seeing some of the examples (usages of this Action out in the wild), it seems worthwhile. But it's just part of the equation.

[bmuenzenmeyer]

I'll defer to you if you think this is valuable. I intend to introduce lighthouse-ci when I have my next chunk of bigger free time

[ovflowd]

Let's merge this; if we don't see value here, we can always revert this.

We can test this by changing a Component that is used within the current Website and see if it generates a report.

[ovflowd]

I can also just run it locally against an older version of the website and paste the results here 🤔

[ovflowd]

📦 Next.js Bundle Analysis for nodejs.org

This analysis was generated by the Next.js Bundle Analysis action. 🤖

⚠️ Global Bundle Size Increased

Page	Size (compressed)
global	136.46 KB (🟢 901 B)

Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

Two Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load
/404	34.1 KB (🟢 -2.87 KB)	170.56 KB
/[...path]	34.05 KB (🟢 -2.86 KB)	170.51 KB

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by undefined% or more, there will be a red status indicator applied, indicating that special attention should be given to this.

[ovflowd]

☝️ comment above is me manually running the stuff locally and pasting the output on the comment above.

[ovflowd]

cc @nodejs/website requesting fast-tracking here so that we can test these changes on currently opened PRs.

[bmuenzenmeyer]

cc @nodejs/website requesting fast-tracking here so that we can test these changes on currently opened PRs.

✅

[ovflowd]

cc @nodejs/website requesting fast-tracking here so that we can test these changes on currently opened PRs.

✅

A thumbs up on the comment usually is enough 👀