How Sitecore’s Default Next.js Dictionary Implementation Can Hurt Performance and Bandwidth Usage

In Sitecore, the dictionary is often used to provide translations for labels, buttons, messages, etc. In simple terms, the dictionary is a way to store text in different languages and easily retrieve it. If you are using Sitecore Headless with Next.js and analyze the page’s payload you will see that it outputs the whole dictionary as props to each and every page.


If you have massively used dictionary in your project, you are basically asking for trouble with this default implementation as each and every page will get the whole dictionary and things that most pages might not even need or use. This can have significant impact on the page payload size.

In the headless world, imagine if your dictionary also stores data for external systems e.g. a mobile app and that data is never really used by the website. Every byte that gets transferred over the wire is costly.

Ideally Sitecore should be smart enough to dynamically include the needed dictionary keys on the page but this is not the case and you have to handle this manually. Unfortunately, there is no implementation that fetches only the necessary dictionary entities for the requested page, thus it can not be configured to pass only necessary dictionary entries.

Sitecore Next.js dictionary implementation

You can check the default dictionary implementation in this file src\rendering\src\lib\dictionary-service-factory.ts. It is a very basic implementation which fetches all of the dictionary keys and include them in props sent to the page.

The “dictionary” is part of the props resolved for a page.

They are fetched in the exec function of NormalModePlugin (src\lib\page-props-factory\plugins\normal-mode.ts) using the dictionaryServices.

If your site does not use the dictionary functionality, feel free to comment out this line of code.

How to improve and optimize Sitecore dictionary implementation

Here are a few ways you can optimize

  1. Only store items in dictionary that are used globally, for example content used in header/footer.
  2. Avoid storing data in dictionary that is not used across the website. Try to use component datasource item to store content instead of dictionary. If you need to share content across multiple instances of a component you can always use Global folder to store it and then reference it from the datasource item.
  3. Separate dictionary items if you are using Dictionary to store data for external systems. You can pass in an additional rootItemId parameter to make sure only relevant keys are made part of your website pages.
  4. If you have to use dictionary massively, consider changing the implementation to a custom one so you can include dictionary items conditionally.
GraphQLDictionaryService({
          endpoint: config.graphQLEndpoint,
          apiKey: config.sitecoreApiKey,
          siteName: config.jssAppName,
          rootItemId: '{879617ED-820E-4551-UA9C-56B206DCDE678}',

Keywords:
Sitecore headless, Next.js Sitecore, Sitecore dictionary optimization, Vercel performance, optimize Sitecore dictionary, Sitecore GraphQL, Sitecore Next.js headless, Sitecore page payload, Next.js performance optimization

Hashtags:
#Sitecore #NextJS #HeadlessCMS #GraphQL #Vercel #WebPerformance #SitecoreOptimization #FrontendPerformance #WebDev #HeadlessArchitecture #SitecoreDictionary

2 thoughts on “How Sitecore’s Default Next.js Dictionary Implementation Can Hurt Performance and Bandwidth Usage

  1. The analysis on Sitecore’s Next.js dictionary implementation and its impact is eye-opening.
    Are there any immediate workarounds or best practices developers can apply to mitigate performance issues before implementing a more permanent solution?

    1. Hi Chris,
      Thank you for you question. Here are a few things you can do.

      1. Only store items in dictionary that are used globally, for example content used in header/footer.
      2. Avoid storing data in dictionary that is not used across the website. Try to use component datasource item to store content instead of dictionary. If you need to share content across multiple instances of a component you can always use Global folder to store it and then reference it from the datasource item.
      3. Separate dictionary items if you are using Dictionary to store data for external systems. You can pass in an additional rootItemId parameter to make sure only relevant keys are made part of your website pages.
      4. If you have to use dictionary massively, consider changing the implementation to a custom one so you can include dictionary items conditionally.

Comments are closed.