Each DB Context will incur a one-off spin-up cost when it is first accessed, so you will want to ensure that a client connection is only touching its own DbContext to avoid that first spin-up waiting on all client DB Context's being touched. For my model I have a common database that the initial login uses to resolve what versioned database a client should be talking to, from there the authenticated user is handed off to their database. The last thing you want is code that iterates over DbContexts in any way.
Edit: The above is not correct, verified with a test. DbContext instances for the same schema hitting different database instances in the same application domain do not incur the spin-up cost. The key factor for a web application is how the application domain is scoped to the request. (considering any load balancing, etc.)
Another factor to consider is to use DB-First and setting the database initializer to #null to avoid any Migrations checks etc. This will save spin-up time.
You can adopt bounded contexts to service key areas of your application(s). The larger and more complex a context definition is, the longer the spin-up takes. By using bounded contexts to cover closely related areas of an application you can cut down on the time needed to spin up a given context on first use. For instance OrderManagementContext, CustomerManagementContext. Entities can be referenced in each context, but you can optimize the definitions where you only need a summary representation in a context that doesn't treat that entity at a top-level. For instance when I'm working with orders, I need a summary of customer. Rather than mapping the whole of Customer and it's related entities that I don't care about, the OrderDbContext maps a OrderCustomer entity which only maps the fields from the Customers table (or view) for the fields I need about a customer when dealing with orders. Fewer, smaller, simpler entities in each context = faster context init.
Lastly, when a user goes to log in, spin up the context(s) early as part of the login process by executing a simple query against one entity in the context. This triggers the initial one-off spin up for the mapping and that way the first "real" query won't get hit with that delay.
using (var orderContext = new OrdersDbContext())
var result = orderContext.Orders.Any();
using (var customerContext = new CustomersDbContext())
var result = customerContext.Customers.Any();
Each of these executes a very fast query, but initialize the mapping for that initial spin-up hit.
Another factor you may to consider beyond minimizing your contexts spin-up cost is any load balancing your environment is doing and possible implications for spin-up costs. The spin up is associated to an application domain, so the questions there will be with load balancing whether that spin-up has to happen on each worker or not. (That's beyond what I know, I'd start with minimizing the context spin up cost, then start peeking down that rabbit hole if it's still needed.)