Part One — Stop Fetching Too Much
This is where most of the wins are.
Cache pages that look the same for everyone
The product pages for instance which gets rendered for un authenticated user are the same for every visit to the page and for any un authenticated user . Making a server call each time in such a scenario is a expensive process the solution cache them and prevent a network call.
The only thing to be noted here is that the pages being cached should never have user data or any real time data to be displayed , the cached pages should never persist any data either as this may cause discrepancy.
Easiest thumb rule to keep in mind here is to strip off the authentication headers here so as to ensure there is no authenticated or user data being retrieved even during the initial fetch
Stop sending data nobody asked for
Spartacus when making a call to commerce will get a default set of parameters in the API response. The question is , is everything utilised? Are all these parameters needed in reality. If not we can always customise what is needed the url param and get back only what is needed making the network calls lighter and quicker.
Similarly on various orientations the slots needed may be lesser than the desktop version using layout.module.ts optimise the layout and the slots to be rendered this will also reduce the burden of the pages API response and make the app respond quicker.
One API call, no matter how many components need the data
In Spartacus the same data from an API response may be used across pages and components, as long as the data is needed afresh making the same call again and again is an expensive process.
Ngrx is to be leveraged here , and using appropriate selectors the data is to be consumed from the store.
In case we need fresh data the loaded flag corresponding the required data in the store is to be made false so that retrieval of data happens with a fresh API call and subsequent components receive the data update via observable streams
Part Two — Make Angular Work Less
Once the API layer is clean, look at how Angular renders the data it receives.
Tell Angular when not to bother re-checking
By default angular checks every component for any event happening like a click , or a key press or a mouse movement it triggers the entire component tree to be checked as the document tree structure grows and as it becomes data heavy this turns out to be sluggish the obvious reason being the change detection needs to run only in the component where the change has occurred.
We can alter this by marking the component to work with a altered change detection approach called "On push"
This ensures only when a input property of that component changes will the change detection run.
For Spartacus components that read from the store, this means Angular only re-renders them when the store data updates. Everything else is ignored.
Tell Angular how to recognise items in a list
Angular is a data driven framework and one of the most commonly used concepts is ngFor where in it iterates over the array and renders the list.
This rendering happens the moment any change happens to the array.
But the question now is if just one of the array item changes rendering the entire DOM tree again is an expensive process. So we need to identify which element of node of the tree has changed this is done using trackBy where in each element or node of tree is identified by a unique identifier.
With this unique identifier only the changed data or node is rendered making it quicker and more efficient also less resource intensive,
Do not load everything upfront
Any site which is loaded is composed of bundles of modules. Now during startup we do not need all modules , for instance a user coming newly to the site needs to complete registration first and wont go to the checkout page right away .
So is it necessary to have the module for the same loaded? No it just makes the bundle heavy and loading process time consuming. This is what happens by default and its a process called eager loading.
We only need to load the modules as and when needed when the user navigates to the required modules. This process is called lazy loading and this needs to be adopted mandatory.
Part Three — Make it Feel Fast
Even a genuinely fast page can feel slow if it shows the user nothing while loading. This section is about perception.
Show the shape of the page before the content arrives
When the API is loading, a blank white page feels like something broke. Even a fast response has a delay.
Skeleton screens fix this. Instead of showing nothing, you show rough placeholder shapes where the content will appear — grey blocks in the size of cards, text, images. Usually with a soft shimmer effect.
The user sees the page "filling in" rather than appearing from nowhere. When the real data arrives, it just swaps in. No jarring blank-to-content jump.
Best part — it's pure CSS. No extra JavaScript, no extra API calls. It shows up instantly because it's already in the HTML the server sent.
Performance is just a habit. Teams that build it in from the start compound their gains over time. Teams that leave it for the end spend the whole project paying the cost.
Bluesky
