Inspector is slow when processing many requests

[martinek]

Describe the bug
I have had this issue for some time now. When I open the inspector and refresh the page, the inspector is slow to respond and slow to show requests. Sometimes it shows requests as pending and it takes a long time for it to reflect completed requests from network tab. This delay can be a few seconds up to a minute and more. After initial requests finish, the interface goes to normal and following requests show up as expected.

I only have this issue when inspecting requests while developing. With vite javascript makes a lot (1000+) of requests to load partial js files and I presume this is causing the issue in inspector. I also get a lot of Error: Could not parse request body from URL in inspector console.

I tried resetting dev tools settings, but the problem persisted.

To Reproduce
I'm not sure how to reproduce it. For me it appears when working on project with many files, so vite makes many requests.

Steps to reproduce the behavior:

1. Open inspector
2. Refresh page
3. Observe slow interface and delayed show of responses.

Expected behavior
Fast and responsive interface

Screenshots

Desktop (please complete the following information):

• OS: macOS Sonoma 14.6.1
• Chrome Version 131.0.6778.70

[jonavila]

Same issue for me. Only happens in Vite dev mode.

[warrenday]

Very likely due to the amount of requests as mentioned then, we have to check all requests to see if they are a graphql request. Potentially this could get quite heavy. We could look at ignoring requests with a certain url pattern, which would be predictable for these dev mode urls.

[Juuldamen]

The ability to be able to ignore certain URL patterns sounds like a good idea to try out to me.

I've added some examples of Vite URL's being loaded in DEV mode in case someone needs an example to implement this. The below URL's are using a self-signed certificate together with a host file rewrite so it is picked up as https by browsers. There might also be folks using similar URL's with localhost:3000 instead.

https://local.example.app/@fs/home/username/dev/example-app/node_modules/.vite/app/deps/@mui_icons-material_Delete.js?v=06f95763
https://local.example.app/@fs/home/username/dev/example-app/node_modules/.vite/app/deps/chunk-EWFAMD4O.js?v=06f95763
https://local.example.app/src/modules/example/index.tsx
https://local.example.app/src/modules/example/routes/example.routes.tsx

Another angle for optimization might be by filtering out requests that are not interesting to the extension from processing. I'm seeing lots of the below error logs, definitely more than the amount of GraphQL requests I'm doing. I haven't looked at the extension's implementation yet, so not sure what is possible. More food for thought :-)

[4799:4799:1121/103503.291383:ERROR:CONSOLE(2)] "Uncaught (in promise) Error: Could not parse request body from URL", source: chrome-extension://ndlbedplllcgconngcnfmkadhokfaaln/static/js/main.7d224dca.js (2)
[4799:4799:1121/103503.291391:ERROR:CONSOLE(2)] "Uncaught (in promise) Error: Could not parse request body from URL", source: chrome-extension://ndlbedplllcgconngcnfmkadhokfaaln/static/js/main.7d224dca.js (2)
[4799:4799:1121/103503.291399:ERROR:CONSOLE(2)] "Uncaught (in promise) Error: Could not parse request body from URL", source: chrome-extension://ndlbedplllcgconngcnfmkadhokfaaln/static/js/main.7d224dca.js (2)
[4799:4799:1121/103503.291407:ERROR:CONSOLE(2)] "Uncaught (in promise) Error: Could not parse request body from URL", source: chrome-extension://ndlbedplllcgconngcnfmkadhokfaaln/static/js/main.7d224dca.js (2)
[4799:4799:1121/103503.291416:ERROR:CONSOLE(2)] "Uncaught (in promise) Error: Could not parse request body from URL", source: chrome-extension://ndlbedplllcgconngcnfmkadhokfaaln/static/js/main.7d224dca.js (2)

[warrenday]

Thanks, for providing. I think the main culprit here is the useNetworkMonitor hook.

https://github.com/warrenday/graphql-network-inspector/blob/master/src/hooks/useNetworkMonitor.ts#L121

The request loads through three events

onBeforeRequest
onBeforeSendHeaders
onRequestFinished

Currently we load all requests into state, then when we get the request headers, and later the response we check if it's a GraphQL query and merge it into state.

Having multiple events is how we're able to show the status as "pending" before the response has loaded.

I think in the handler for onBeforeRequest we can add some simple and fast filtering (maybe on url patterns) to avoid the later heavy validation which involves json parsing.

[warrenday]

I don't mind looking into this. But if anyone is able to pop up a reproducible demo, that would be a massive help!

[martinek]

@warrenday Here is demo project. It doesn't do anything, it is just vite project with lot of imported files.

https://github.com/martinek/graphql-network-inspector-154demo

It is react app, there is import for slow and very slow :) (1000 vs 9999) files.

You can reproduce the issue by running the app, then opening it in browser and opening the inspector. After refresh, you can observe the issue.

[warrenday]

Thanks @martinek !