Service worker responds slowly (10 seconds) when many query parameters are present #3077

Activity

1. westonruter

   changed the title [-]Service worker responds slowly (1)[/-] on May 5, 2022
2. westonruter commented on May 5, 2022

   

   westonruter

   on May 5, 2022

   ContributorAuthor

   More actions

   I just saw that the user was running PWA plugin v0.6 which included Workbox v5. I'm asking them to update to v0.7 which includes the current Workbox version to see if that fixes the issue.
3. jeffposnick

   added

   Needs More InfoWaiting on additional information from the community.Waiting on additional information from the community.

   on May 5, 2022
4. westonruter commented on May 5, 2022

   

   westonruter

   on May 5, 2022

   ContributorAuthor

   More actions

   Actually, I can reproduce the issue on my own site with the latest versions installed.

   • Responds quickly after 115ms: https://weston.ruter.net/
   • Responds slowly after 9s: https://weston.ruter.net/?ab=4&v0=56&u0=degrees+Celsius+%28%C2%B0C%29&f0=C&v1=60&u1=degrees+Celsius+%28%C2%B0C%29&f1=C&v2=0.0005&u2=per+degree+Celsius+%28%2F%C2%B0C%29&f2=CdT&v3=100&u3=centimetres+%28cm%29&f3=cm&u4=centimetres+%28cm%29&f4=cm&v5=100&u5=sq+centimetres+%28cm%C2%B2%29&f5=sqcm&v6=100.4&u6=sq+centimetres+%28cm%C2%B2%29&f6=sqcm&v7=100&u7=cu+centimetres+%28cc%2C+cm%C2%B3%29&f7=cucm&v8=100.6&u8=cu+centimetres+%28cc%2C+cm%C2%B3%29&f8=cucm

   Service worker URL: https://weston.ruter.net/wp.serviceworker
   Workbox version: 6.5.3
5. jeffposnick commented on May 5, 2022

   

   jeffposnick

   on May 5, 2022

   Contributor

   More actions

   This is due to the denylist functionality in the service worker's navigation routing:

   

   The following RegExps are each being tested against the long pathname + search:

   1. /^\/wp\-admin($|\?.*|\/.*)/
   2. /[^\?]*.\.php($|\?.*)/
   3. /.*\?(.*&)?(wp_service_worker)=/
   4. /.*\/wp\.serviceworker(\?.*)?$/
   5. /[^\?]*\/feed\/(\w+\/)?$/
   6. /\?(.+&)*wp_customize=/
   7. /\?(.+&)*customize_changeset_uuid=/
   8. /^\/wp\-json\/.*/

   I can't tell you offhand which one of them is giving you particularly bad performance when tested against that long input, but it normally tends to be a RegExp that does a bunch of backtracking. You could try removing them one by one from your denylist until you find the one(s) that are expensive, and then attempt to optimize it.

   I'm going to close this issue, since it appears to be more about how Workbox is configured than about the core functionality. Let me know if there's anything else I can do to assist, though.

   ❤️React with ❤️1Reacted by Weston Ruter
6. jeffposnick

   closed this as completedon May 5, 2022
7. jeffposnick

   added

   workbox-routing

   and removed

   Needs More InfoWaiting on additional information from the community.Waiting on additional information from the community.

   on May 5, 2022
8. jeffposnick commented on May 5, 2022

   

   jeffposnick

   on May 5, 2022

   Contributor

   More actions

   ...one more thing is that if you really need to keep the current set of RegExps in your denylist, but you want them matched against just the pathname portion of the URL, you could do that pretty easily via a custom matchCallback:

   const denylist = [/.../, /.../];
   const navigationMatcher = ({request, url}) => {
     if (request.mode !== 'navigate') {
       return false;
     }
     for const (regexp of denylist) {
       if (regexp.test(url.pathname)) {
         return false;
       }
     }
     return true;
   };
   
   registerRoute(
     navigationMatcher,
     SomeStrategy(),
   );

   This would help if you know that it's unlikely for folks to have a very long path, while it's more likely for them to have a lot of query parameters.

   You could also get more fine-grained to how you match your path segments while avoiding RegExps if you need to:

   const skipIfSegmentMatches = ['skip1', 'skip2'];
   const navigationMatcher = ({request, url}) => {
     if (request.mode !== 'navigate') {
       return false;
     }
     const segments = url.pathname.split('/');
     for const (segment of skipIfSegmentMatches) {
       if (segments.includes(segment)) {
         return false;
       }
     }
     return true;
   };
   
   registerRoute(
     navigationMatcher,
     SomeStrategy(),
   );
9. westonruter commented on May 6, 2022

   

   westonruter

   on May 6, 2022

   ContributorAuthor

   More actions

   Thanks a lot! I was able to identify these two patterns as causing the expensive backtracing:

   /\?(.+&)*wp_customize=/
   /\?(.+&)*customize_changeset_uuid=/
   

   I'm going to optimize those and then consider your improved denial logic for the future.

   🙇