I wonder if there is a performance difference between capacitorHttp and normal web fetch.
When using capacitorHttp, since the request occurs on the native side, it doesn’t affect the main thread of the webview, so it might be more beneficial from a javascript and html paint performance.
On the other hand, since there’s an additional process of exchanging data between the native and the webview via a bridge, it could negatively impact the overall performance of the app.
What do you guys think? If it’s not due to issues like Cookie/Session/CORS, is there no advantage to using capacitorHttp purely in terms of performance?
I believe in the past a Capacitor team member said to use fetch over Capacitor HTTP if possible. As you mentioned, there is that extra overhead of serializing/deserializing the data between the web layer and the native layer.
I personally only use the web stack for HTTP calls in my app and don’t see any issues.
Hello @twestrick, is there any way to use capacitorHttp for specific urls?
In my case, one of npm package(which I cannot control) is causing a CORS error, but I don’t want all of my “fetch” requests to be handled by capacitorHttp.
@julio-ionic, what about the requests that I cannot control? For example, firebase npm package has CORS problem for host capacitor://localhost, and I cannot control their own requests.
I did some researches and I concluded that there is no way to use capacitorHttp only for the firebase URLs. I have Blob upload feature as well, so I cannot enable capacitorHttp globally.
I hope there should be some configuration for enabling capacitorHttp for certain URLs, such as