static-web-apps-cli: Proxied requests for static content through the SWA CLI are very slow

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:

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

About this issue

Original URL
State: open
Created a year ago
Reactions: 10
Comments: 17 (4 by maintainers)

Most upvoted comments

@cjk7989 - you’d asked for feedback https://github.com/Azure/static-web-apps-cli/issues/663#issuecomment-1639742914 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.

cjk7989 on Aug 8, 2023

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.

AverageCakeSlice on Oct 2, 2023

This issue is still not fixed and the SWA CLI is practically unusable for local development beyond static testing. This is clearly visible in a blank Nuxt app that takes around 15-30 seconds to refresh vs a few ms when opened directly. Will this be fixed at some point @cjk7989 ?

itpropro on Feb 26, 2024

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.

dgcaron on Nov 28, 2023

Just copying over from https://github.com/Azure/static-web-apps-cli/pull/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 ❤️

johnnyreilly on Nov 7, 2023

I’ve raised a PR to revert the changes causing the slow proxying: https://github.com/Azure/static-web-apps-cli/pull/758

johnnyreilly on Oct 24, 2023

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.

andrewreeman on Aug 3, 2023