I’m currently building a web application with a FastAPI backend and a frontend served using Live Server during development. I’ve noticed a strange behavior, and I would love to get some insights into why this is happening and how it is typically handled in production.

What I Noticed: First request lag: When I make a request from the frontend to the backend for the first time (which involves processing some data), the response is delayed and doesn’t return promptly. However, on subsequent requests, the data is fetched quickly because it’s cached from the previous request.

The request works fine on the second try, but the first request lags.

OpenAPI Docs behavior: Interestingly, when I test the same endpoint using the OpenAPI Docs (which is auto-generated by FastAPI), the response is returned immediately, even on the first request.

What I Found in DevTools: In the browser’s DevTools, I noticed that a WebSocket connection is being established on first load of the page (even though my FastAPI backend is not using WebSockets at all). The WebSocket connection doesn’t seem to be used for anything directly in the backend, yet it’s active during the first request.

This WebSocket connection appears to be automatically initiated by the Live Server (which is serving the frontend), likely for live reloading purposes, and it conflicts with my regular HTTP request to FastAPI. The WebSocket connection might be causing the delay in the first request, as it seems to hold up the resources for the HTTP request, which leads to the lag I observe.

My Questions: Why does this lag occur on the first HTTP request when there’s no direct WebSocket logic in my backend, and how does this conflict between WebSocket and HTTP requests happen during development?

How do engineers handle this situation in production environments where both WebSocket connections (for real-time features like notifications) and regular HTTP requests are needed?

Specifically, how do they prevent these two types of connections from interfering with each other, even if the frontend code is initiating both WebSocket and HTTP requests (like in my case)? How does this issue not arise in production, where WebSocket and HTTP traffic are both required, but they work smoothly without conflicts (e.g., no first-request lag)?

If both WebSocket and HTTP requests are handled by the same frontend code (like mine), how do companies ensure that they don’t interfere with each other in live environments? I imagine API gateways or separate subdomains could be involved, but I would appreciate a simple explanation of how this works in production.

Context: My frontend is served using Live Server on port localhost:5500, and the FastAPI backend is running on localhost:8000.

The behavior I see only occurs in the development environment, and I’m interested in understanding how engineers would handle such a scenario in production to avoid similar issues.

Additional Info: I’m not looking for a solution to the development setup (as I understand that Live Server and WebSocket conflicts can occur during local development), but rather a clarification on how this situation would be prevented in production where both WebSocket and HTTP need to coexist without issues. Specifically, how can engineers set up their systems in production to avoid this kind of interference between WebSocket and HTTP requests, even when the same frontend code initiates both.