Menu
Menu Sheet Overlay
Search
Search Sheet

      Query Parameter Filtering for Server-Side Rendered PWAs

      Note: Query parameter filtering, discussed below, is only applicable to server-side rendered PWAs.

      Introduction

      Your Progressive Web App (PWA) may require the use of query parameters, which can threaten the performance of your server-side rendered PWA. This article will provide you with an overview of what query parameters are, the specific problem they pose for cache-based site performance, and how you can use Mobify’s query parameter filtering feature to benefit from query parameters, without any of the performance issues.

      Query parameters

      Query parameters are specific parameters that can be added to the end of a URL to define specific content or actions. For example, marketing teams can use query parameters to track purchases from an email marketing campaign, by assigning a specific parameter to the email marketing campaign and appending it to the end of the URL.

      As an example, a URL with a query string may look like this:

      http://example.com/products?name=green

      Notice how the question mark introduces the query string. In this case, the query string is name=green. After receiving this request, a server will pass the query string along to any programs that get run.

      The problem for performance

      One reason that Mobify’s server-side rendered PWAs are extremely fast is that content can be cached in the content delivery network. When a specific URL is requested, the content delivery network compares the URL (also known as the cache key), with those that are already in the cache. The comparison includes the origin, path and query parameters of the URL.

      Suppose a URL has already been cached, and that there is a second variation with a unique query parameter appended to the end. The added query parameter would mean that the cache key does not match, therefore the page would be treated like a new URL. In the example of the email campaign, every link using a query parameter is unique, meaning that each shopper would need to have their page re-loaded rather than using the cached version, costing precious load time.

      The solution: query parameter filtering

      Query parameter filtering is a feature which allows you to use query parameters, but with none of the associated impacts to cache-based site performance. When a URL is requested from the content delivery network, query parameter filtering can edit the set of query parameters, removing any query parameters that would affect caching beyond those required by the server. The content delivery network can then better cache responses because URLs are more likely to match. The browser will still see the original query parameters, and can report them to analytics. The request sent to the server will not see any query parameters that have been removed.

      Let’s revisit the example of the email marketing campaign. Now, the page from the email marketing campaign can be served from the cache for most browsers, and the unique tracking links would still be intact.

      Steps to use query parameter filtering

      To use query parameter filtering, you need to:

      1. Create a request-processor: It must be called request-processor.js, and stored in the same directory as your main.jsx file. For projects using the old scaffold (projects generated before March 2019), this is located in the your-project/web/app sub-directory. For projects using the new scaffold (projects generated after March 2019), this is located at your-project/packages/pwa/app/.

      2. Update the processRequest function: within request-processor.js, you must update the function called processRequest so that it processes requests in whatever way your project requires. For details on parameters and return values, visit packages/pwa/app/request-processor.js.example.

      Example

      The following example shows a possible processRequest implementation, but keep in mind that for your own implementation, you should replace it with code that processes your unique project requests. To view the most up-to-date version of this example in the code, it’s accessible at packages/pwa/app/request-processor.js.example.

      /**
      * This example uses only the querystring parameter to processRequest. There are
      * other parameters that may be needed for other uses of the request-processor,
      * and these are documented in the Scaffold's example request-processor.
      * 
      * @returns {{path: *, querystring: *}}
      */
      export const processRequest = ({ path, querystring }) => {
      
         // This example will remove any of the parameters whose keys appear
         // in the 'exclusions' array.
         const exclusions = [
             'gclid',
             'utm_campaign',
             'utm_content',
             'utm_medium',
             'utm_source'
         ]
      
         // Build a first QueryParameters object from the given querystring
         const incomingParameters = new QueryParameters(querystring)
      
         // Build a second QueryParameters from the first, with all excluded
         // parameters removed
         const filteredParameters = QueryParameters.from(
             incomingParameters.parameters.filter(
                 // parameter.key is always lower-case
                 (parameter) => !exclusions.includes(parameter.key)
             )
         )
      
         // Re-generate the querystring
         querystring = filteredParameters.toString()
      
         // Return the path unchanged, and the updated query string
         return {
             path,
             querystring
         }
      }

      IN THIS ARTICLE:

      Feedback

      Was this page helpful?