Optimization of @sitecore-jss/sitecore-jss library for usage with Next.js

[Antonytm]

Is your suggestion related to a problem? Please describe.

@sitecore-jss/sitecore-jss has quite a big size.

According to bundlephobia https://bundlephobia.com/package/@sitecore-jss/[email protected] it is 31 KiB minified.

Self-code is only 7.3%. The other big parts are graphql, graphql-request, axios, cross-fetch, debug, and url-parse.

These parts should be included in the client-side bundle only if we make requests on the client side. Otherwise, we don't need them in the client bundle. (debug we don't need at all, but that is just 4%).

---

Let's focus on GraphQL. (The case with other libraries is similar, but it will make the explanation more clear.)

It is my feeling, but usage of GraphQL requests on the client side is an rather exception than the rule. The major part of Next.js implementations uses Integrated GraphQL + Connected GraphQL in GetStaticProps. See discussions in #headless channel in Sitecore Slack. But even if my feeling is wrong, even if GraphQL is used by 90% of implementations, you should not be forced to include this library in the client bundle.

---

Test setup:

1. Next.js Styleguide based on ^21.1.0 (I didn't notice any breaking change to reproduce it on the latest version)
2. Removed "GraphQL" pages from Sitecore
3. Removed src/components/graphql/ folder

In other words, we emulate the case, when connected GraphQL is not used at all. And there is no reason to include it in the client bundle.

---

Analyzing bundle

I will use two approaches:

1. Next Bundle Analyzer https://www.npmjs.com/package/next-bundle-analyzer. I described how to use it here: https://exdst.com/posts/20231201-sitecore-nextjs-bundle
2. Lighthouse report to make sure that Next Bundle Analyzer doesn't lie.

---

Commands to run

1. npm run start:production. (npm-run-all --serial bootstrap next:build next:start)

---

Bundle review

Lighthouse results:

Next Bundle Analyzer:

(GraphQL is in red, and other potential gains are in yellow)

Describe the solution you'd like

Option 1 (harder, but probably the right way from architectural point of view):

I assume that the problem had happened because there were React, Vue, and Angular implementations. Then the the same core library was applied to Next.js. But Next.js is a full-stack framework. (Or backend framework with React on the client side if you wish). And if we use some library that has both server-side and client-side code then all code is added to the client bundle. Probably there is not enough magic during Next.js/Webpack bundle optimization. But it is, what it is.

@sitecore-jss library could be split into 2 parts:

1. Server side
2. Client side

In this case, the usage of the same library for React/Vue/Angular might look strange

Or another way to split:

1. GraphQL/Axios dependent
2. No GraphQL/Axios dependent

That might be not the best for Next.js. But it will make more sense for all frameworks together. Data fetching related part. And the other.

I tried to make a prototype, but GraphQL is too tightly coupled with sitecore-jss, so it may take months to make a proper split.

---

Option 2 (easy):

Use peer dependencies instead of dependencies in package.json.
Below is the scenario that I have tried to check that this approach may work.

1. Starting point: the same styleguide(without GraphQL) Next.js Sitecore website that was used for baseline measurement.
2. Edit node_modules\@sitecore-jss\sitecore-jss\package.json and move graphql to peerDependencies

  "dependencies": {
    "axios": "^0.21.1",
    "chalk": "^4.1.0",
    "debug": "^4.3.1",
    "lodash.unescape": "^4.0.1",
    "memory-cache": "^0.2.0",
    "url-parse": "^1.5.9"
  },
  "peerDependencies": {
    "graphql": "^16.5.0",
    "graphql-request": "^4.2.0",
  },

3. Remove node_modules\@sitecore-jss\sitecore-jss\node_modules\graphql and node_modules\@sitecore-jss\sitecore-jss\node_modules\graphql-request folder to make sure that this libraries are not used
4. In other words, in steps 1-3, I emulate usage peerDependencies by @sitecore-jss\sitecore-jss package without changes in the package itself.
5. Run npm run start:production. (npm-run-all --serial bootstrap next:build next:start)
6. Verify that the website still works exactly the same
7. Analyze bundle and Lighthouse reports

Lighthouse report shows a decrease in 9KiB compared to the baseline:

Next Bundle Analyzer shows a decrease in 9KiB compared to the baseline and the absence of the GraphQL library in the final bundle.
(There are some other GraphQL-related libraries. It will require an additional look, at why they are bundled as dependent.)

Of course, all these changes should be done in the package itself. But not in the node_modules folder with the existing package.

Is there a way to achieve this functionality with exisiting tools?

All other ways that I am aware are "hacks":

1. "Monkey-patching" of content inside node_modules using some additional npm tasks
2. Fork and build "lite" @sitecore-jss/sitecore-jss with no extra dependencies
3. Hardcode node_modules folder content by adding it to GIT

Additional information

If you need some extra information - I am open for a call.

[Antonytm]

PR was created
#1705

[Antonytm]

I found another option 3.

  webpack: (config, { isServer, webpack }) => {
    if (!isServer) {

      config.resolve.alias = {
        ...config.resolve.alias,
        'graphql-request': path.resolve(__dirname, 'src/fake/graphql-request.js'),
        'graphql': path.resolve(__dirname, 'src/fake/graphql.js'),
        'axios': path.resolve(__dirname, 'src/fake/graphql.js'),
        
      };
    }
    return config;
  },
    webpack: (config, { isServer, webpack }) => {
    if (!isServer) {

      config.resolve.alias = {
        ...config.resolve.alias,
        'graphql-request': path.resolve(__dirname, 'src/fake/graphql-request.js'),
        'graphql': path.resolve(__dirname, 'src/fake/graphql.js'),
        'axios': path.resolve(__dirname, 'src/fake/axios.js'),
      };
    }
    return config;
  },

It was inspired by this article https://arunoda.me/blog/ssr-and-server-only-modules
(However, for Sitecore JSS + Next.js, these 3 methods described in the article don't work for me)

[Antonytm]

Also, I build 2 sites to check if it is worth it:
Without graphql and axios: https://jss-nextjs-optimized-sample.netlify.app/styleguide
Default(with graphql and axios): https://jss-nextjs-sample.netlify.app/styleguide

Sorry, no images due to local Sitecore.

[yavorsk]

Hi @Antonytm, thanks for your detailed investigation, all of this makes sense :) I've created a task in our back log to discuss internally your suggestions (also included the pr re moving axios and graphql to peer dependencies #1705 )

[Antonytm]

Hi @yavorsk

Thank you for looking into it.

Please, consider the PR that I opened as direction, but not as a final solution.
It decreases size of core sitecore-jss:
https://bundlephobia.com/package/@sitecore-jss/[email protected]
https://bundlephobia.com/package/@exdst/[email protected]

But to achieve the final result, it will also require to have changes sitecore-jss-react and sitecore-jss-nextjs.

[yavorsk]

Understood @Antonytm, thank you.

[Antonytm]

https://youtu.be/ik8KzhCjw_4?t=1430
See one of the possible scenarios on how to improve it in an action.