The Terrible Performance Cost of CORS Request on the Single-Page Application

The Terrible Performance Cost Of CORS Request, on thesingle-page application(SPA).

The title may let you think that this post as another ranting post about the downside of “Single Page Application”, but this is more about throwing some light from the performance perspective to keep in mind while designing the SPA  ,that consumes API from different domain services that most of the article or courses teaching you SPA doesn’t talk about.

If you are designing an SPA which consumes the API from the same domain of SPA then great, you read no further down if not interested.

But when we live in “microservices” world, where we consume different endpoints of services serving on different domain within the SPA, adding resilience, fault tolerance etc, improving user experience of our product, multiple domain request becomes inevitable until and unless we strictly adhere’s to the same domain app API Gateway — Microservices Pattern for our SPA.

SPA + Cors not always reduces the latency.

Let’s Imagine we have a Get API /users/report/:id served from domain api.example.com and our SPA is served from spa.example.com , where  :id means its a value that can change, with Content-Type header value as application/json for every request.

Can you guess the issue with the above API design with respect to CORS and its impact on the performance of our SPA ?

Brief Introduction of CORS as on MDN .

The CORS is all good until it’s a simple request that doesn’t trigger a CORS preflight.

But most often we make request that are not “ simple request ” either due to the fact that we need to send a header that is not cors-safelisted-request-header , such as Authorization, x-corelation-id , etc, and more frequently our Content-Type header value is application/json which again is not an allowed values for the Content-Type header for cors-safelisted-request-header .

Now when our api.example.com server accepts content-type of application/json , our SPA domain spa.example.com will first send an HTTP request by the OPTIONS method to the resource /users/report/12345 on the other domain api.example.com , in order to determine whether the actual request is safe to send. Cross-site requests are always preflighted like this since they may have implications for user data.

It’s a job of api.example.com server to let the other domain spa.example.com know it’s safe to send the data. You might have done something similar to this for CORS inside your Application.

Allowing CORS on Express.js Server

Once the api.example.com server sends the proper response from “OPTIONS” method to other domain spa.example.com then only the actual data with the request you were trying to make is done.

So to access a resource api.example.com/users/report/12345 two actual request was performed.

You might say yes but then we can use the Access-Control-Max-Age header to cache the results of a preflight request, so that next time when we access a resource api.example.com/users/report/12345 from spa.example.com there is no preflight request.

Yes that’s true, but then remember the title — The Terrible Performance Cost Of CORS Request, on the single-page application (SPA), comes from the API that we’re are consuming and the way it’s has been designed. In our example, we designed our API /users/report/:id , where  :id means its a value that can change.

The way preflight cache work is per URL not just the origin, meaning that any change in the path, (which includes query parameters) warrants another preflight request.

So In our case to access resource api.example.com/users/report/12345 and api.example.com/users/report/123987 will trigger to 4 requests from our SPA in total.

If you have a slow network, this could be a huge setback, especially when an OPTIONS request takes 2 seconds to respond, and another 2 for the data.

Now imagine your SPA application making millions of such request for different domains, and its terrible impact on your SPA performance when you’re effectively doubling the latency of every request.

SPA is great in its own domain. But for consuming different domain it comes with its own cost, and if the API has not been designed properly, the latency issues of your SPA Application can hurt you even more than the benefits that you want to rip from SPA.

There is no solution or technology that is good or bad, knowing it’s shortcoming and what it takes from you make it right, is what differentiate your Application from the others.