Final Update & Solution A big thank you to everyone who provided suggestions! After extensive testing based on your feedback, I've finally identified the root cause of the ~8 second cold start time.

The bottleneck was the database connection to the PostgreSQL instance running inside WSL2.

The Experiment

Following the advice to isolate variables, I tried switching the database connection to a different instance:

1. I set up a new PostgreSQL instance running directly on the Windows host.
2. I also tested with a local SQL Server Express instance running on Windows.

The results were immediate and dramatic. When connecting to either of the native Windows database instances, the initial application load time dropped to a perfectly normal 200-300 milliseconds. The 8-second delay completely vanished.

This proves that the issue was not with EF Core's model compilation time, nor was it with the Blazor Server framework's JIT compilation. The entire ~8-second delay was being consumed by the initial database connection (dbContext.Database.CanConnectAsync()) from my Blazor app on the Windows host to the PostgreSQL server inside WSL2.

While using localhost to connect from Windows to WSL2 works, it appears to have a significant performance overhead for database connections in this scenario, leading to an unexpectedly long initial connection time that mimics a framework cold-start issue.

I also recall that to resolve other unrelated network issues in the past, I had modified the MTU size inside my WSL2 instance by adding the following command to my ~/.bashrc file:

sudo ip link set dev eth0 mtu 1350

This is the most relevant reason I can think of.