proxying via SWA CLI is slow #554
-
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
Hi, do you have a repo that I can use to investigate the issue? |
Beta Was this translation helpful? Give feedback.
-
Hi @bzbetty so after investigating the issue, I found out about the cause. I'll send a fix that's gonna boost the performance of the local dev experience by ~70%. Thank you again for reporting this performance issue 👍 Here is a graph showing the perf boost. Please note that given how the SWA CLI local emulator is architecture, it's challenging for us to beat the framework dev server. This is why the numbers of the SWA CLI load time are slightly higher than the framework dev server HTTP server. FWIW, when configuring the SWA CLI to connect to your dev server, we are basically proxying all requests to that dev server, and this obviously adds some extra time to the overall load time. sequenceDiagram
participant Browser
participant SWACLI
participant ViteCLI
Browser->>SWACLI: GET index.html
SWACLI->>ViteCLI: GET index.html
ViteCLI->>ViteCLI: Read html content from disk
ViteCLI->>SWACLI: html content
SWACLI->>Browser: html content
|
Beta Was this translation helpful? Give feedback.
Hi @bzbetty so after investigating the issue, I found out about the cause. I'll send a fix that's gonna boost the performance of the local dev experience by ~70%. Thank you again for reporting this performance issue 👍
Vite dev server:
SWA CLI
Here is a graph showing the perf boost.
Please note that given how the SWA CLI local emulator is architecture, it's challenging for us to beat the framework dev server. This is why the numbers of the SWA CLI load time are slightly higher than the framework dev server HTTP server.
FWIW, when configuring the SWA CLI to connect to your dev server, we are basically proxying all requests to that dev server, and this obviously adds some extra time to th…