+
+
+
+
+
+
+
+
+
+
+
+ );
+}
+```
+
+This effect is more interesting on pages that include more than one component, where each can take a different time to load (due to more complex backend logic, database access, network delays, or other causes).
+
+Let's take a look at [another example](https://demo-dxp.openselfservice.com/en/personal/help-and-support), this time a digital experience portal with a knowledge base area. Once more, each component is streamed to the browser as soon as it's ready and is then available to interact with:
+
+
+
+While the fallback components are not sized to perfectly match their full counterparts, they don't have to be. It's enough for them to be "close enough", just so that they can be visually similar to the final rendered components, especially considering that some content will be very dynamic when it e.g. depends on a CMS configuration.
+
+As already mentioned, using Suspense has the additional benefit of reducing [Cumulative Layout Shift](https://web.dev/articles/cls). Let's see what this process would look like if only one block did not provide any fallback states and notice how the article tiles "jump down" when the tiles above them appear:
+
+
+
+While this is a mostly harmless example, just take a look at another, more dangerous example from [web.dev](https://web.dev/articles/cls):
+
+
+
+It's obvious that providing appropriate placeholders is critical not only to increase the overall performance (a high CLS will lower your Lighthouse score) but also to safeguard against potentially harmful actions.
+
+So to sum up - this pattern eliminates the "waterfall" effect where one component must finish loading before the next one begins, significantly reducing the overall page load time. As a side effect, it can also provide a better user experience. Instead of using a single loader for the whole page or even delaying the page rendering until every single piece of data is fetched and ready for rendering, you can actually show the page loading progress.
+
+### Component-level dynamic imports
+
+Beyond block-level code splitting, we use dynamic imports for heavy components within blocks. This is particularly beneficial, e.g., for data visualization components that rely on large third-party libraries:
+
+```typescript
+'use client';
+
+import dynamic from 'next/dynamic';
+
+// Dynamically import the chart component to reduce initial bundle size
+const StackedBarChart = dynamic(
+ () => import('@o2s/ui/components/Chart/StackedBarChart').then((module) => module.StackedBarChart),
+);
+
+export const PaymentsHistoryClient = ({ title, chartData }) => {
+ return (
+
+ {title}
+ ...
+
+ );
+};
+```
+
+In this example, the chart component (which depends on the [recharts library](https://recharts.org/)) is dynamically imported only when needed (in other words, when that block is rendered on the frontend). Chart libraries are typically large and would significantly increase the initial bundle size, and typically not every page in the app will contain a chart component - so there's no point in preloading a resource-heavy library before it's actually necessary.
+
+### API composition layer
+
+The API composition layer serves as a critical intermediary between frontend blocks and backend services. It can be implemented in a variety of different ways, but we chose to use [Nest.js](https://nestjs.com/) as a framework which fits in nicely in the whole TypeScript-based tech stack.
+
+As an example for what we can achieve using such architecture, let's look at the service that is responsible for the endpoint for fetching data for the `OrderDetails` block:
+
+```typescript
+// Data aggregation from multiple sources
+export class OrderDetailsService {
+ constructor(
+ // Service for fetching static content e.g. from some CMS
+ private readonly cmsService: CMS.Service,
+ // Service that returns dynamic data for the user from some backend API
+ private readonly orderService: Orders.Service,
+ ) {}
+
+ getOrderDetailsBlock(params, query, headers) {
+ const cms = this.cmsService.getOrderDetailsBlock({ ...query, locale: headers['x-locale'] });
+ const order = this.orderService.getOrder({ id: params.id });
+
+ // Fetch data from both sources simultaneously
+ return forkJoin([cms, order]).pipe(
+ map((order) => {
+ // Transform and combine data for the frontend app
+ return mapOrderDetails(cms, order);
+ }),
+ );
+ }
+}
+```
+
+This approach provides several benefits for the overall performance. Firstly, the composition layer combines data from multiple backend services into a single, optimized response that is specifically tailored for each block - returning only the information that block needs and nothing else, which eliminates overfetching.
+
+Instead of making multiple API calls directly from the browser (e.g. for user actions like filtering or form submissions), the composition layer handles the communication with backend services, which reduces latency and bandwidth usage. The composition layer can fetch data from multiple sources in parallel using, for example, [RxJS observables](https://rxjs.dev/), optimizing the overall response time
+
+Additionally, raw data from various backend services is transformed into a consistent format, which does not necessarily improve performance itself but allows the frontend to be implemented in an API-agnostic way.
+
+### API-level caching
+
+However, in a composable architecture where each block independently fetches its own data, there's a risk of redundant API calls to the same backend services. Therefore, it's important to also provide a caching mechanism that can help to reduce the load on backend services.
+
+We chose to address this issue by leveraging [Redis](https://redis.io/) that can e.g. cache static CMS responses for use in other blocks. While, of course, some static content is still very block-dependant, other is shared - like general config or reusable generic translations - and can be safely cached.
+
+In our framework, blocks don't need to implement caching logic themselves; they benefit automatically from the centralized caching system. When multiple blocks on a page require the same underlying data, the first request populates the cache, and subsequent requests are served from the cache without hitting the backend services.
+
+### Request memoization
+
+Next.js 13 and later versions introduced an important performance optimization feature: automatic request memoization. It ensures that identical data fetching requests within the same render pass are actually called only once, significantly reducing unnecessary network calls and improving performance.
+
+This is especially important for composable apps where the frontend does not define every page, instead relying on a CMS configuration. In such cases, there will be, for example, two identical requests needed for a single page render: one to [generate metadata](https://nextjs.org/docs/app/getting-started/metadata-and-og-images#generated-metadata) and the second to actually render page body:
+
+```typescript jsx
+export async function generateMetadata({ params }: Props): Promise
+```
+
+This output is based on [deviceSizes config](https://nextjs.org/docs/app/api-reference/components/image#devicesizes) that you can also adjust to your own needs. For example, you might want to narrow down the list of possible viewports if your app is very image-heavy to simply save on the amount of HTML generated:
+
+```typescript
+deviceSizes: [430, 828, 1200, 2048, 3840]
+```
+
+At the end it's quite critical to monitor LCP and preloads in Lighthouse and check if it's possible to adjust the `priority` if you see that lazy loading:
+
+- does not occur on images below-the-fold
+- or it does occur for images above-the-fold
+
+## Conclusion
+
+Building high-performance composable frontends requires addressing challenges across multiple architectural levels. The approach we've described combines modular architecture with Next.js server components for efficient rendering, strategic Suspense boundaries for progressive loading, and an API composition layer that optimizes data flow. We further enhance performance through caching, request memoization, and component-level dynamic imports.
+
+These strategies deliver real benefits: faster page loads, smoother interactions, and responsive applications even under challenging network conditions. For developers, the composable approach improves maintainability, simplifies testing, and allows independent evolution of different application parts.
+
+As shown in the Lighthouse performance audits, these optimizations result in excellent scores across all Core Web Vitals and performance metrics:
+
+
+
+The Open Self Service framework demonstrates this in practice, providing a foundation for building performant composable applications that scale with business needs while delivering exceptional user experiences. This approach is particularly effective in enterprise environments where complex integration requirements, high traffic, and demanding performance standards are common. Open Self Service delivers outstanding results by enabling organizations to build fast, maintainable frontends that seamlessly integrate with multiple backend systems while achieving superior performance metrics.
+
+Want to see it in action?
+
+- [**Open Self Service website**](https://www.openselfservice.com)
+- [**Documentation**](https://www.openselfservice.com/docs)
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-1.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-1.png
new file mode 100644
index 00000000..b9af2192
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-1.png differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-2.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-2.png
new file mode 100644
index 00000000..aa91d4c6
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/lighthouse-2.png differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-1.gif b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-1.gif
new file mode 100644
index 00000000..35d9e0c9
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-1.gif differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-2.gif b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-2.gif
new file mode 100644
index 00000000..85044369
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/multi-block-loading-2.gif differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/order-details-block.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/order-details-block.png
new file mode 100644
index 00000000..d86e10d5
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/order-details-block.png differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/single-block-loading.gif b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/single-block-loading.gif
new file mode 100644
index 00000000..7ba39018
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/single-block-loading.gif differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-desktop.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-desktop.png
new file mode 100644
index 00000000..41bf8e89
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-desktop.png differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-mobile.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-mobile.png
new file mode 100644
index 00000000..1f66c5be
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes-mobile.png differ
diff --git a/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes.png b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes.png
new file mode 100644
index 00000000..980c0209
Binary files /dev/null and b/apps/docs/blog/articles/ensuring-high-frontend-performance-in-composable-nextjs-apps/sizes.png differ
diff --git a/apps/docs/blog/tags.yml b/apps/docs/blog/tags.yml
index 2fed2137..6a796dcf 100644
--- a/apps/docs/blog/tags.yml
+++ b/apps/docs/blog/tags.yml
@@ -8,7 +8,6 @@ tech:
permalink: '/tech-articles'
description: 'Content related to technology or development of O2S.'
-
integrations:
label: 'Integrations'
@@ -18,6 +17,9 @@ frontend:
backend:
label: 'Backend'
+performance:
+ label: 'Performance'
+
# An empty tag definition is also valid
# Other attributes will be inferred from the key
emptyTag:
diff --git a/apps/docs/src/pages/index.tsx b/apps/docs/src/pages/index.tsx
index bc39e8be..8b27fbbb 100644
--- a/apps/docs/src/pages/index.tsx
+++ b/apps/docs/src/pages/index.tsx
@@ -51,9 +51,9 @@ export default function Home(): ReactNode {
self-service experiences using Next.js, TypeScript, and NestJS.