Skip to main content

Sitecore JSS SDK Middleware Issue with Large Query Parameters

Recently, a fellow Sitecorian connected with me to discuss an interesting performance issue with a Sitecore JSS application running on Next.js and Vercel.

The application was working perfectly fine for normal URLs. However, when users accessed the website through marketing or advertising URLs containing multiple query string parameters, the requests started taking significantly longer and eventually failed.

The interesting part was that the same page worked perfectly when the query parameters were removed.

Let's understand what was happening and how to fix it.

The Problem

The application was using Sitecore JSS with Next.js and hosted on Vercel.

Normal URLs were working as expected:

https://www.example.com/

Even URLs with a few query parameters were working:

https://www.example.com/?p1=1&p2=2&p3=3&p4=4&p5=5

But when the number of query parameters increased, the request started taking much longer and eventually failed.

In some cases, we were seeing errors such as:

504: MIDDLEWARE_INVOCATION_TIMEOUT

and:

500: JavaScript heap out of memory

This was particularly concerning because marketing URLs commonly contain parameters such as:

utm_source
utm_medium
utm_campaign
gclid
gbraid

So a URL generated by an advertising or marketing platform could behave differently from a normal URL.

Business needed these URLs to work as soon as possible due to an upcoming marketing campaign.

The Investigation

Initially, it is easy to suspect Vercel because the error is coming from the middleware execution.

However, after looking at the behavior more closely, there was an interesting pattern.

The page itself was not the problem.

If we removed the query string parameters, the page loaded correctly.

If we added a small number of parameters, it still worked.

As the number of parameters increased, the response became slower and eventually failed.

For example, we could test with something like this:

https://www.example.com/?p1=1&p2=2&p3=3&p4=4&p5=5

and then increase the number of parameters:

https://www.example.com/?p1=1&p2=2&p3=3&p4=4&p5=5&p6=6&p7=7&p8=8

This helped isolate the problem.

The issue was not related to a particular marketing parameter. The number of query string parameters itself was enough to reproduce the problem.

What is happening in Sitecore JSS Middleware?

The Sitecore JSS Next.js application uses middleware to process requests before they reach the application.

The problem was traced to the middleware implementation in the Sitecore JSS version being used.

In the affected version, processing a large number of URL search parameters was not efficient.

As the number of parameters increased, the middleware consumed more execution time and memory.

Eventually, the middleware could exceed the limits of the platform.

This is why the behavior can be a little confusing.

A page may work perfectly when accessed directly but fail when a user arrives through a marketing campaign URL.

How to check if your application is affected

The first thing I would check is the version of the Sitecore JSS Next.js package in package.json.

Look for:

"@sitecore-jss/sitecore-jss-nextjs": "..."

The issue described by Vercel affects Sitecore JSS versions starting with 22.2.0 and before 22.6.0.

So if your application is using one of these versions, this should be investigated.

You can also check the installed version using:

npm list @sitecore-jss/sitecore-jss-nextjs

or:

yarn why @sitecore-jss/sitecore-jss-nextjs

How to reproduce the issue

One simple way to verify the problem is to gradually increase the number of query parameters.

Start with:

https://www.example.com/?p1=1&p2=2&p3=3

Then try:

https://www.example.com/?p1=1&p2=2&p3=3&p4=4&p5=5

and continue increasing the number of parameters.

If the application works with a small number of parameters but becomes slow or fails when more parameters are added, this is a good indication that you should investigate the JSS middleware.

It is also worth checking the Vercel function logs for the failing requests.

In our case, this type of testing helps separate an application/page performance problem from a middleware problem.

The Solution

The recommended solution is to upgrade the Sitecore JSS Next.js package.

Upgrade:

@sitecore-jss/sitecore-jss-nextjs

to:

22.6.0

or a later version.

The performance issue has been addressed in the later JSS release.

After upgrading the package, rebuild and deploy the application and repeat the same test with URLs containing a large number of query parameters.

You should also test your actual marketing URLs because those are the URLs most likely to expose the problem.

What if you cannot upgrade immediately?

If an immediate upgrade is not possible, one temporary option is to reduce the number of query parameters being added to campaign URLs.

For example, review whether all tracking parameters are really required.

However, I would consider this only a workaround.

Marketing and advertising platforms can generate URLs with different combinations of tracking parameters, so relying on a small number of parameters is not a reliable long-term solution.

The better solution is to upgrade the affected JSS dependency.

Conclusion

This is one of those issues which can be difficult to identify because the website itself may appear to be working perfectly.

The problem may only appear when a user comes through a marketing campaign URL containing many query parameters.

If you are using Sitecore JSS with Next.js on Vercel and seeing:

504: MIDDLEWARE_INVOCATION_TIMEOUT

or:

JavaScript heap out of memory

when URLs contain many query parameters, check your Sitecore JSS version before spending too much time looking at the page-level code.

In particular, check whether you are using an affected version of @sitecore-jss/sitecore-jss-nextjs.

Upgrading to 22.6.0 or later is the recommended solution.

Hope this helps you!

Labels:

Comments

Post a Comment

POPULAR POSTS

Sitecore PowerShell Script to create all language versions for an item from en version

  We have lots of media items and our business wants to copy the data from en version of media item to all other language versions defined in System/Languages. This ensures that media is available in all the languages. So, we created the below powershell script to achieve the same -  #Get all language versions defined in System/Languages $languages = Get-ChildItem /sitecore/System/Languages -recurse | Select $_.name | Where-Object {$_.name -ne "en"} | Select Name #Ensuring correct items are updated by comparing the template ID  $items = Get-ChildItem -Path "/sitecore/media library/MyProjects" -Recurse | Where-Object {'<media item template id>' -contains $_.TemplateID} #Bulk update context to improve performance New-UsingBlock (New-Object Sitecore.Data.BulkUpdateContext) { foreach($item in $items){    foreach($language in $languages){ $languageVersion = Get-Item -Path $item.Paths.Path -Language $language.Name #Check if language versi...
Post a Comment
Read more

Export Sitecore media library files to zip using SPE

If you ever require to export Sitecore media files to zip (may be to optimize them), SPE (Sitecore Powershell Extension) has probably the easiest way to do this for you. It's as easy as the below 3 steps -  1. Right click on your folder (icons folder in snap)>Click on Scripts> Click on Download 2. SPE will start zipping all the media files placed within this folder. 3. Once zipping is done, you will see the Download option in the next screen. Click Download Zip containing the media files within is available on your local machine. You can play around with the images now. Hope this helps!! Like and Share ;)
Post a Comment
Read more

Make Sitecore instance faster using Roslyn Compiler

When we install the Sitecore instance on local, the first load is slow. After each code deploy also, it takes a while for the Sitecore instance to load and experience editor to come up. For us, the load time for Sitecore instance on local machines was around 4 minutes. We started looking for ways to minimize it and found that if we update our Web.config to use Roslyn compiler and include the relevant Nugets into the project, our load times will improve. We followed the simple steps - Go to the Project you wish to add the NuGet package and right click the project and click 'Manage NuGet Packages'. Make sure your 'Package Source' is set to nuget.org and go to the 'Browse' Tab and search Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Install whichever version you desire, make sure you note which version you installed. You can learn more about it  here . After installation, deploy your project, make sure the Microsoft.CodeDom.Providers.DotNetCompilerPlatform.d...
1 comment
Read more

Experience of a first time Sitecore MVP

The Journey I have been working in Sitecore for almost 10 years now. When I was a beginner in Sitecore, I was highly impressed by the incredible community support. In fact, my initial Sitecore learning path was entirely based on community written blogs on Sitecore. During a discussion with my then technology lead Neeraj Gulia , he proposed the idea that I should start giving back to developer community whenever I get chance. Just like I have been helped by many developers via online blogs, stackoverflow etc., I should also try to help others. Fast forward a few years and I met  Nehemiah Jeyakumar  (now an MVP). He had a big archive of his technical notes in the form Sitecore blogs. I realized my first blog dont have to be perfect and it can be as simple as notes to a specific problem for reference in future. That's when I probably created my first blog post on Sitecore. At that time, I didn't knew about the Sitecore MVP program. Over the years, I gained more confidence to writ...
2 comments
Read more

Clean Coding Principles in CSharp

A code shall be easy to read and understand. In this post, I am outlining basic principles  about clean coding after researching through expert recommended books, trainings and based on my experience. A common example to start with is a variable declaration like - int i  The above statement did not clarify the purpose of variable i. However,  the same variable can be declared as -  int pageNumber The moment we declared the variable as int pageNumber, our brain realized that the variable is going to store the value for number of pages. We have set the context in our brain now and it is ready to understand what the code is going to do next with these page numbers. This is one of the basic advantages of clean coding. Reasons for clean coding -  • Reading clean code is easier - Every code is revisited after certain amount of time either by the same or different developer who created it. In both the cases, if the code is unclean, its difficult to understand and u...
Post a Comment
Read more