-
Notifications
You must be signed in to change notification settings - Fork 913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Web client initial load is very slow (90 seconds) in Chrome (compared to Firefox - 4 seconds) #5385
Comments
Hmm, might be the preflight OPTIONS requests, which the ESP32 responds with 404 and 'Connection: close': OPTIONS /api/v1/fromradio?all=false HTTP/1.1 HTTP/1.1 404 Not Found |
Code link for 404 showing explicit 'Connection: close': https://github.com/meshtastic/esp32_https_server/blob/896f1771ceb5979987a0b41028bf1b4e7aad419b/src/HTTPConnection.cpp#L277 |
Recent CORS policy issue, not sure if related: meshtastic/web#249 |
/api/v1/fromradio doesn't seem to have a OPTIONS handler? |
Serial log during this:
|
This avoids hitting the 404 Not Found handler, which breaks connection keep-alive, so this change fixes a big performance regression for Web Client in Chrome: meshtastic#5385
This avoids hitting the 404 Not Found handler, which breaks connection keep-alive, so this change fixes a big performance regression for Web Client in Chrome: meshtastic#5385 Tested on Heltec V3.
This avoids hitting the 404 Not Found handler, which breaks connection keep-alive, so this change fixes a big performance regression for Web Client in Chrome: meshtastic#5385 Tested on Heltec V3.
This avoids hitting the 404 Not Found handler, which breaks connection keep-alive, so this change fixes a big performance regression for Web Client in Chrome: meshtastic#5385 Tested on Heltec V3.
This avoids hitting the 404 Not Found handler, which breaks connection keep-alive, so this change fixes a big performance regression for Web Client in Chrome: #5385 Tested on Heltec V3. Co-authored-by: Ben Meadors <[email protected]>
Category
WiFi
Hardware
Heltec V3
Firmware Version
2.5.11.8e2a3e5
Description
Chrome (~90 seconds):
Screen.Recording.2024-11-17.at.2.51.14.PM.1.mov
Firefox (~4 seconds):
Screen.Recording.2024-11-17.at.2.59.48.PM.1.mov
I think this is because Chrome re-establishes the connection (TCP+TLS) for each request:
Connection keep-alive is supposed to work, and make a huge difference, as seen in Firefox, where each request takes only ~60 ms.
I thought I figured out the reason Chrome connections don't keep alive but I found some conflicting clues so now I'm not so sure I understand why.
Relevant log output
No response
The text was updated successfully, but these errors were encountered: