2

On our JSS/Next.js site, we are running into an issue issue with poor PageSpeed performance scores, which are mostly attributable to large JS bundles. They're so large because we have one large main.js, due to the way that a typical JSS/Next.js site is set up with with a generic, catch-all route: [[...path]].tsx. This results in one large bundle being used on every page.

We have looked into numerous solutions, such as using the bundle analyzer to optimize as much as possible (see this helpful thread). We also leveraged lazy loading in Next.js which split out the home page into separate bundles, which while slightly smaller overall, introduced a different kind of overhead; more network requests.

As of now, we can't reduce the bundles any further unless we start splitting the bundle out by individual pages. In other words, each page's bundle would contain only what it needs. Some front end frameworks, including Next.js, do this (AKA code/bundle splitting). However, the catch-all route of JSS makes this more challenging. How might we approach this in a JSS/Next.js solution?

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.