Proxied requests for static content through the SWA CLI are very slow

[geoffrich]

• Before filing this issue, please ensure you're using the latest CLI by running swa --version and comparing to the latest version on npm.

Are you accessing the CLI from the default port :4280 ?

• No, I am using a different port number (--port) and accessing the CLI from that port
• Yes, I am accessing the CLI from port :4280

Make sure you are accessing the URL printed in the console when running swa start!

ℹ️ NOTE: Make sure to enable debug logs when running any swa commands using --verbose=silly

Describe the bug
When I run a Vite app behind the SWA CLI, requests for static files take much longer through the SWA emulator (port 4280) than if I access the Vite app directly (5173). For example, requesting the same static file can take about 1 second through SWA, but only a couple milliseconds through the Vite dev server directly. Network tab screenshots are below.

This especially affects the startup performance of any apps using Vite with SWA, since Vite apps serve many small static files in development.

To Reproduce
I created a repo showing the issue: https://github.com/geoffrich/swa-cli-issue-repro. If you clone this repo, you can skip to step 5 on the below repro steps.

Steps to reproduce the behavior:

1. Init a new Vite app with npm create vite@latest (tested with both the Svelte and React presets)
2. cd into the created project
3. Install the SWA CLI with npm i -D @azure/static-web-apps-cli@latest
4. Init the CLI config with npx swa init. Accept default values.
5. Run the SWA emulator with npx swa start
6. Access the site at localhost:4280. Open the network tab and notice that requests for the JS files take ~1 second.
7. Access the Vite app directly at localhost:5173. Open the network tab and notice that requests for the JS files take only a few milliseconds.

Expected behavior
Requests for static files are not significantly slower when running behind the SWA emulator.

Screenshots
Network tab on localhost:4280 (note request times of 1 second for each static file)

Network tab on localhost:5173 (note request times of a few milliseconds)

Desktop (please complete the following information):

• OS: MacOS
• Version: Ventura 13.4.1

Additional context
Add any other context about the problem here.

[andrewreeman]

I've also experience similar behaviour. Using version 1.1.3 seems fine for me. But using 1.1.4 dramatically slows down loading. As a complete guess, maybe due to something in this commit: f1dd587916d76b267d0d46da47d26ea0ae898a22 . Great that it can now support node 18 though due to that commit.

[burkeholland]

I'm experiencing this behavior as well. I've ended up architecting my app around anything that doesn't force me to do a full page reload (I.e. avoiding stores) because the reload time is so slow.

[johnnyreilly]

As much as I love that a fix to #663 has landed - the performance issues really impair the developer experience. It's very slow.

@cjk7989 - you'd asked for feedback here so I wanted to give you a heads up. As much as it pains me, I think I'm going to downgrade to 1.1.3 and reimplement my workaround here:

https://johnnyreilly.com/static-web-apps-cli-node-18-could-not-connect-to-api

Sorry to be the bearer of not joyful feedback 😢

As a side note, I think Windows users running Node.js 18 might need 1.1.4 to be able to run. I'm using a Mac and so I don't - but I think me downgrading to 1.1.3 is not going to work for everyone.

[cjk7989]

@cjk7989 - you'd asked for feedback #663 (comment) so I wanted to give you a heads up. As much as it pains me, I think I'm going to downgrade to 1.1.3 and reimplement my workaround here:

Hi all, sorry for the issue, the reason might be that swa-cli uses wait-on to test if localhost should be resolved to ipv4 or v6, which causes a lot of await.

We will further investigate it and look for a good solution to support node 18 without loss of speed. Thanks for reporting that.

By the way, if you decide to downgrade to 1.1.3, then before doing that, please make sure your apis and database connection can work (which means your function-core-tools and dataApiBuilder has been correctly installed). If you are using dev servers like Angular and React, please set hostname to [::1] instead of localhost. Feel free to let me know your issue.

[burkeholland]

FWIW, I'm using 1.1.3 with 18.17.0 without issue. App is a Vite/Vue application.

[zwergius]

I had to downgrade to 1.0.3 to get dev server speed back to normal, guess node 18 will have to wait 🤷‍♂️

[AverageCakeSlice]

Just wanted to chime in here as well to say that this is my experience as well with 1.1.4

Here's a screenshot of my performance. I'm working with a Vue 3 + Vite 3.1.0 project. From what I've observed, it looks like the assets are being loaded in groups of 2-4 files, with about a 500ms delay between each group. It can take certain pages over a minute to load in like this, depending on the number of components required on the specific page.

Downgrading to 1.1.3 works on Node 18.18.0 for me; the delays are completely gone.

[AlbinNewSeed]

Also experienced this on 1.1.4, downgraded to 1.1.3.

[johnnyreilly]

Looking at jeffbski/wait-on#137 (comment)

It's possible that the Node.js 18 issue that lead to the changes in 1.1.4 and slowness may not surface in Node.js 20. If so, then the changes in 1.1.4 could be rolled back.

[johnnyreilly]

Ah it turns out that the SWA CLI doesn't presently support Node.js 20 and so testing this may be an issue:

#756 (comment)

[johnnyreilly]

I've raised a PR to revert the changes causing the slow proxying: #758

[cjk7989]

In swa-cli@v1.1.5, we have reduced some delays so that the requests to dev servers will be handled faster. Please feel free to install it, and let us know if you think further optimization is needed.

[johnnyreilly]

Just copying over from #758

Thanks for this - I did some testing on the perf differences between 1.1.3, 1.1.4 and 1.1.5 when it was in alpha state. Things have improved, but 1.1.5 is still roughly half the speed of 1.1.3.

I took our most demanding client side app, and timed the initial startup with 1.1.3, 1.1.4 and 1.1.5-alpha for comparison. 1.1.5-alpha was half as performant as 1.1.3 - see the screenshots from devtools below:

1.1.3

1.1.4

1.1.5-alpha

In response to this @cjk7989 has said:

Hi @johnnyreilly, we can't revert to 1.1.3 to speed up because the bug of resolving localhost will occur with node 18 in some systems. But I agree with you to record the successful responder and use that to steer all subsequent requests. We will design a fallback method to resolve requests in the future update. Thanks!

I'm quite keen on seeing what effect a fallback method might have on improving performance. In the meantime I'm glad things have improved between 1.1.4 and 1.1.5 ❤️

[dgcaron]

for anyone running into this issue, i just upgraded the swa cli to 1.1.6 and it seems to have a very positive effect on the load time.