Technical review: Server-side Composition vs. Client-side Composition

 Corresponding author: Shafi Shaik. Copyright © 2025 Author(s) retain the copyright of this article. This article is published under the terms of the Creative Commons Attribution License 4.0. Technical review: Server-side Composition vs. Client-side Composition Shafi Shaik * Independent Researcher, USA. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 Publication history: Received on 12 April 2025; revised on 19 May 2025; accepted on 21 May 2025 Article DOI: https://doi.org/10.30574/wjarr.2025.26.2.1941 Abstract Micro frontend architecture has emerged as a transformative paradigm for building scalable and maintainable web applications by extending microservices principles to the frontend. This technical review explores the fundamental dichotomy between server-side and client-side composition strategies within micro frontend implementations. Serverside composition assembles page fragments before delivery to the browser, while client-side composition delegates this process to JavaScript in the client's browser. The document examines implementation mechanisms for both approaches, including Server-Side Includes (SSI), Edge-Side Includes (ESI), and Backend for Frontend (BFF) patterns for server-side composition, alongside Web Components, Module Federation, and framework-specific solutions for client-side composition. Performance characteristics are thoroughly evaluated, highlighting how server-side composition typically delivers faster initial page loads and improved SEO, while client-side composition excels at subsequent interactions and developer autonomy. The review also addresses development workflows, testing strategies, and deployment considerations that significantly differ between approaches. Through case studies in e-commerce and enterprise dashboards, it demonstrates how each strategy suits different application types. A decision framework is presented to guide architects in selecting appropriate composition approaches based on performance requirements, team structures, and business contexts, with many modern applications benefiting from hybrid implementations that strategically combine both paradigms. Keywords: Micro Frontends; Server-Side Composition; Client-Side Composition; Web Architecture; Component Integration 1. Introduction Micro frontend architecture has emerged as a significant approach for building scalable and maintainable web applications, with adoption rates increasing substantially in recent years. According to industry research, 72% of enterprises are now implementing or planning to implement micro frontend architectures for their web applications [1]. This architectural pattern extends the microservices concept to the frontend, allowing teams to develop, test, and deploy UI components independently. While traditional monolithic frontends become increasingly complex and difficult to maintain as applications grow, micro frontends provide a solution by breaking down the user interface into smaller, more manageable parts that can be developed by independent teams. A critical decision when implementing micro frontends is choosing between server-side composition and client-side composition. These two approaches represent fundamentally different strategies for assembling application fragments into a cohesive user experience. Server-side composition assembles page fragments on the server before delivery to the client, while client-side composition delegates this assembly process to the browser using JavaScript. Performance metrics indicate that server-side composition typically results in faster initial page loads, while client-side composition offers improved interactivity for complex applications after the initial load. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3038 The micro frontend approach addresses several key challenges in modern web development, including scalability issues in large teams, technology stack limitations, and deployment complexities [2]. By decomposing the frontend into smaller, independent units, organizations can achieve greater development velocity, with teams working in parallel on different sections of the application without coordination bottlenecks. This architectural style also enables incremental upgrades to both technology stacks and user interfaces, allowing for gradual modernization rather than risky complete rewrites. Implementation data shows that organizations adopting micro frontends typically experience reduced time-to-market for new features and improved ability to scale development teams effectively [1]. However, this approach introduces its own complexity in terms of integration, consistency, and performance optimization. The choice between server-side and client-side composition significantly impacts these factors, with each approach offering distinct advantages and trade-offs for different use cases. This technical review analyzes both approaches in depth, examining their implementation mechanisms, performance implications, development workflows, and appropriate use cases to help technical teams make informed architectural decisions. As web applications continue to grow in complexity and importance to business operations, understanding these architectural options becomes increasingly critical for organizations seeking to maintain development agility while delivering optimal user experiences. 2. Technical Foundations of Composition Approaches 2.1. Server-side Composition Mechanisms Server-side composition relies on server infrastructure to combine micro frontend fragments before sending the final HTML to the client. Recent studies indicate this approach significantly reduces initial page load times compared to client-side implementations across enterprise applications [3]. Several implementation mechanisms enable this approach: 2.1.1. Server-Side Includes (SSI) SSI directives, supported by web servers like Nginx and Apache, allow including content from one file into another during server processing. These are among the oldest and simplest forms of server-side composition. Using special directive syntax, SSI enables servers to include fragments from various sources directly into the HTML before delivery to the client. Despite their age, SSI remains widely used due to its simplicity and efficiency for static content integration [3]. 2.1.2. Edge-Side Includes (ESI) ESI provides a more sophisticated inclusion mechanism that operates at the CDN level, enabling fragment-level caching. With ESI, content delivery networks can assemble page fragments with different caching requirements, optimizing both performance and freshness of content. ESI syntax allows developers to specify different time-to-live (TTL) values for various fragments on the same page, which research shows can substantially reduce server load and bandwidth usage for high-traffic websites [3]. 2.1.3. Server-Side Rendering (SSR) Frameworks Modern frameworks like Next.js, Nuxt.js, and Remix facilitate server-side composition through component-based rendering pipelines. These frameworks serve as composition layers that aggregate data and render complete pages. Industry surveys show that a majority of developers use SSR frameworks for micro frontend composition, with improved SEO performance frequently cited as the primary motivation [4]. 2.1.4. Backend for Frontend (BFF) Pattern BFF implementations often serve as composition layers, aggregating data and markup from multiple backend services before delivering complete pages to specific frontend clients. The adoption of the BFF pattern has grown substantially in recent years, with many organizations implementing micro frontends now utilizing BFF approaches for their composition needs [4]. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3039 2.2. Client-side Composition Techniques Client-side composition delegates the assembly of micro frontends to the browser runtime. This approach has evolved considerably with modern JavaScript frameworks. Analysis shows that while client-side composition tends to enhance developer productivity, it often requires more careful performance optimization compared to server-side approaches [4]. 2.2.1. Web Components Custom elements provide a standards-based approach for creating encapsulated, reusable components. Web Components use a combination of Custom Elements, Shadow DOM, and HTML Templates to create independent, reusable UI elements that can be composed together at runtime in the browser. These components maintain their own styling and functionality, making them ideal building blocks for client-side composition. Studies indicate adoption of Web Components for micro frontend architectures has increased significantly in recent years [4]. 2.2.2. JavaScript Module Federation Webpack 5's Module Federation enables runtime sharing of JavaScript modules across independently deployed applications. This technology allows multiple separate builds to form a single application, with one build being able to dynamically import code from another at runtime. Module Federation creates a type of "distributed require()" that can be used to import modules from remote sources, enabling true decoupling of micro frontends while maintaining efficient code sharing [3]. 2.2.3. Framework-specific Solutions Various frameworks provide specialized solutions for client-side composition, including Single-SPA, which enables multiple frameworks to coexist in a single page; qiankun, which extends Single-SPA with additional features for React, Vue, and Angular applications; and Luigi, a micro frontend framework that supports UI composition with a central navigation concept. 2.2.4. Iframes and Web Workers Figure 1 Micro Frontend Composition Approaches: Server-side vs Client-side [3, 4] Traditional techniques like iframes provide strong isolation between components, while Web Workers enable background processing without blocking the main thread. Despite newer alternatives, iframes still account for a significant portion of client-side micro frontend implementations, primarily in highly regulated industries where strict isolation is required for security compliance [3]. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3040 3. Performance considerations 3.1. Server-side Composition Performance Profile 3.1.1. Initial Load Performance Server-side composition typically delivers faster Time to First Contentful Paint (FCP) as it sends pre-rendered HTML to the browser. Research across e-commerce websites confirms that server-side composed pages achieve significantly better FCP times compared to client-side composed equivalents [5]. For content-focused applications, this provides substantial user experience benefits, particularly on slower networks or devices. Mobile users on 3G connections experience even more dramatic improvements, with server-side composition substantially reducing initial render times and decreasing bounce rates proportionally to improved loading time [5]. 3.1.2. Backend Processing Overhead The composition process consumes server resources and can introduce latency in page delivery. This becomes particularly significant with complex scenarios. Analysis of high-traffic websites implementing server-side composition reveals that each additional fragment increases server processing time, with the effect compounding non-linearly as fragments increase [5]. Complex compositions involving many fragments can increase server response time depending on implementation quality. In comparative benchmarks, applications with more numerous distinct fragments showed additional server processing time compared to simpler compositions. High request volumes significantly impact performance, with server-side composition facing scaling challenges at high traffic thresholds. During peak traffic events, ESI implementations typically show better resilience than SSI approaches, maintaining better performance at multiple times normal traffic volumes. Dynamic, personalized content that cannot be effectively cached presents the greatest challenge, with personalized server-side composed pages requiring substantially more CPU resources than their cached counterparts. User-specific content fragments increase page generation time proportionally to the number of personalized components [6]. 3.1.3. Caching Strategies Server-side composition enables sophisticated fragment-level caching at the edge, allowing different parts of a page to have different cache lifetimes based on their update frequency. Effective implementation of ESI with fragment-specific TTLs demonstrates better cache hit ratios for partially dynamic pages compared to traditional full-page caching approaches [6]. Analysis of high-traffic e-commerce platforms found that fragment caching reduces origin server load and decreases average response time during peak traffic periods. The most sophisticated implementations dynamically adjust fragment cache durations based on content volatility, achieving optimal freshness-versus-performance balance [6]. 3.2. Client-side Composition Performance Considerations 3.2.1. Initial Load vs. Subsequent Interactions Client-side composition typically involves performance trade-offs between initial and subsequent page views. Research across production SPA implementations reveals several patterns: Client-side composed applications deliver significantly larger JavaScript payloads compared to server-side equivalents. Module Federation implementations can reduce this overhead compared to non-shared dependency approaches [5]. Time to Interactive (TTI) measurements show client-side composed applications require additional time to become fully interactive compared to server-rendered counterparts, especially on mid-range mobile devices. Subsequent navigation performance due to client-side caching provides significant advantages after initial load. Navigation between routes in client-side composed applications requires much less time compared to traditional multipage server-rendered applications [6]. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3041 3.2.2. Progressive Loading Patterns Client-side approaches can implement sophisticated loading strategies that mitigate initial performance concerns. Code splitting to load only necessary JavaScript reduces initial bundle sizes and improves First Input Delay (FID) metrics [6]. Lazy loading components when they enter the viewport shows substantial benefits for long-scrolling pages, decreasing initial page weight while maintaining equivalent conversion rates. Priority-based loading of critical vs. non-critical components demonstrates significant optimization potential, achieving FCP and TTI improvements compared to standard client-side rendering approaches [5]. 3.2.3. Runtime Resource Consumption Multiple JavaScript frameworks running concurrently in client-side composition led to increased memory usage and potentially cause performance degradation on resource-constrained devices. Multi-framework compositions increase memory consumption compared to single-framework equivalents [5]. JavaScript execution time on mobile devices increases proportionally for each additional framework included in the same page, with particularly severe impacts on devices with limited RAM. Applications using three or more distinct frameworks on a single page trigger browser crash on low-end devices more frequently than single-framework implementations and exhibit significant visual stuttering during user interactions [6]. Figure 2 Server-side vs. Client-side Composition: Key Performance Factors [5, 6] 4. Development and Operational Implications 4.1. Team Autonomy and Development Workflow 4.1.1. Server-side Composition Workflows Server-side composition often requires more coordinated development approaches. Research across engineering teams implementing micro frontends indicates that those using server-side composition report higher levels of centralized governance [7]. The development workflows typically include centralized deployment coordination, which remains necessary for most server-side composition implementations. Organizations with larger frontend development teams spend significantly more time on cross-team deployment coordination compared to client-side approaches [7]. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3042 Shared implementation standards for fragment interfaces are critical, with most surveyed teams mandating organization-wide conventions for server-side fragment contracts. These standards typically cover HTTP headers, content negotiation mechanisms, and error handling protocols. Integration testing of the composition layer represents a substantial portion of quality assurance efforts in server-side composition projects. Organizations implementing comprehensive automated testing for composition layers report fewer production incidents related to fragment integration failures [8]. Potential bottlenecks for deployment emerge when multiple teams contribute to the same compositional surface. Analysis of deployment frequency across micro frontend implementations revealed that server-side composition teams deployed less frequently on average than their client-side counterparts, with many citing cross-team dependencies as the primary limiting factor [7]. 4.1.2. Client-side Composition Workflows Client-side composition typically enables greater team autonomy but introduces different operational complexities. Among surveyed engineering organizations, a majority reported higher team velocity after adopting client-side composition approaches [7]. Independent deployment of micro frontends becomes significantly more feasible, with most client-side implementations achieving deployment independence between teams. Organizations experience increased deployment frequency after transitioning from monolithic frontends to client-side composed micro frontends [8]. Team autonomy in technology selection is a primary benefit, with most client-side implementation teams having authority to select their own framework and tools. In diversified technology environments, teams use various frameworks including React, Vue.js, Angular, and others within the same application [8]. Decentralized deployment processes are implemented by most client-side micro frontend teams, with organizations reporting reduced deployment lead time after transitioning to decentralized CI/CD pipelines. Interestingly, many organizations maintain some form of centralized monitoring despite decentralized deployment [7]. Contract-based integration between components becomes essential as autonomy increases. Teams employing formal contract testing report fewer integration issues compared to those relying solely on manual testing approaches. The implementation of standardized contract testing tools corresponds with a decrease in integration-related incidents across surveyed organizations [8]. 4.2. Testing Strategies 4.2.1. Server-side Testing Approaches Testing for server-side composition focuses on different aspects than client-side approaches. Research indicates that server-side testing strategies require more test coverage to achieve equivalent quality assurance [7]. Server-side integration tests for fragment assembly form the foundation of quality assurance, comprising a substantial portion of testing efforts in server-side composition projects. Organizations implementing automated integration testing at the composition layer report fewer production incidents related to fragment integration failures [8]. Performance testing of the composition process is critical, with most server-side implementations conducting regular load testing specifically for the composition layer. Organizations that implement comprehensive performance testing detect potential bottlenecks before production deployment more effectively than teams without dedicated composition performance testing [7]. 4.2.2. Client-side Testing Approaches Client-side composition testing emphasizes different concerns, with organizations reporting higher test automation complexity compared to server-side equivalents [7]. Browser compatibility testing becomes significantly more complex, with client-side micro frontend teams testing across more browser/device combinations than server-side implementations. Organizations implementing automated cross-browser testing report capturing most compatibility issues before production [8]. Integration testing in realistic runtime environments is critical, with nearly all client-side implementations requiring specialized approaches for testing component interactions. Performance testing across various device profiles is essential, with most client-side teams conducting testing on multiple distinct device profiles. Contract testing between World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3043 independently deployed components becomes a cornerstone of quality assurance, with most client-side teams employing formalized contract testing approaches [7]. 4.3. Deployment and Release Management 4.3.1. Server-side Deployment Considerations Server-side composition creates distinct deployment challenges that require specific strategies. Orchestrated releases of the composition layer are necessary for most server-side implementations, with organizations typically employing dedicated release coordination teams [7]. Canary releases by controlling fragment selection offers significant risk mitigation, with many organizations utilizing fragment-level canary deployments. Blue-green deployment strategies for the composition infrastructure are implemented by a majority of organizations using server-side composition, resulting in reduced user-perceived downtime during deployments [8]. 4.3.2. Client-side Deployment Considerations Client-side composition introduces different deployment challenges but offers greater flexibility. Client-side approaches demonstrate higher deployment frequency but require more sophisticated runtime management [8]. Independent versioning and deployment of micro frontends is achieved by most client-side implementations, with organizations reporting numerous independent deployments per week across frontend teams. Version compatibility management across components becomes crucial, with most organizations implementing explicit version compatibility verification. Feature flags and runtime configureuration to control component behavior are employed by the vast majority of clientside micro frontend implementations, enabling faster feature rollout velocity and more granular control over feature availability [7]. Figure 3 Implementation Characteristics: Server-side vs. Client-side [7, 8] 5. Use Cases and Decision Frameworks 5.1. Optimal Use Cases for Server-side Composition Server-side composition excels in specific scenarios where performance and accessibility are paramount. Industry surveys of micro frontend implementations indicate that server-side composition is predominantly selected for content-focused applications and e-commerce platforms [9]. This approach demonstrates particular advantages in scenarios requiring maximum initial page load performance, with server-side composed sites achieving significantly faster First Contentful Paint metrics than equivalent client-side implementations. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3044 Search engine optimization without complex SSR solutions provides significant ranking advantages. Analysis of ecommerce sites reveals that server-side composed pages achieve higher organic search visibility and better conversion rates from organic traffic compared to client-side rendered equivalents [10]. Support for low-powered devices with minimal JavaScript capabilities remains critical for global audiences, with performance testing showing that server-side composition reduces CPU utilization on entry-level smartphones and extends battery life during browsing sessions. Reduced client-side JavaScript payloads represent a substantial benefit, with server-side implementations delivering considerably less JavaScript on initial page load compared to client-side alternatives. Content-heavy applications where rendering performance is critical show the most dramatic benefits, with news and media sites implementing serverside composition reporting lower bounce rates and longer average session durations [9]. 5.1.1. Case Study: E-commerce Product Pages E-commerce platforms often leverage server-side composition to optimize product page loading times, combining fragments like headers, product details, recommendations, and reviews while applying appropriate caching strategies to each section. Major online retailers implementing server-side composition with Edge-Side Includes report increased conversion rates after migration from client-side architecture. Such implementations allow different page fragments to be cached independently, with static elements cached for longer periods while dynamic content has shorter cache lifetimes [10]. This granular caching approach reduces origin server load during peak shopping periods while improving Time to Interactive. Transaction volumes typically increase following implementation, with mobile conversions showing particularly significant improvements [9]. 5.2. Optimal Use Cases for Client-side Composition Client-side composition is particularly effective for applications requiring rich interactivity and developer flexibility. Frontend architects predominantly select client-side composition for application-centric interfaces requiring extensive user interaction [10]. Highly interactive, application-like experiences benefit most from client-side composition, with the majority of SaaS products and enterprise applications implementing this approach. User interface testing reveals that client-side composed applications achieve better response times for user interactions after initial load and smoother transitions between interface states. Dashboard interfaces with multiple interactive widgets show particular affinity for client-side approaches. Studies of enterprise analytics platforms find that client-side composed dashboards support more concurrent interactive visualizations with lower latency for data manipulation operations compared to server-rendered equivalents [10]. Scenarios where teams need complete technology independence benefit substantially, with organizations reporting higher developer satisfaction and faster feature delivery when implementing client-side composition. Applications requiring sophisticated state management across components show faster development cycles with clientside composition, with engineering teams spending less time implementing complex interaction patterns and troubleshooting state synchronization issues. Progressive enhancement of existing applications proves more feasible with client-side composition, allowing organizations to modernize legacy applications incrementally without disrupting core business operations [9]. 5.2.1. Case Study: Enterprise Dashboard Applications Enterprise dashboards frequently employ client-side composition to allow different teams to independently develop and deploy widgets for analytics, reporting, and monitoring, while maintaining a cohesive user experience. Financial services corporations implementing client-side composition using Web Components and Module Federation for internal analytics platforms can support numerous distinct teams contributing to a unified dashboard interface [10]. Such implementations enable deployment frequency to increase from periodic to daily releases, with individual teams deploying updates regularly. Time-to-market for new analytics capabilities decreases substantially, while cross-team dependencies diminish. These platforms can integrate multiple data visualization libraries across various teams while maintaining consistent design systems, resulting in increased system development velocity in the months following implementation [9]. World Journal of Advanced Research and Reviews, 2025, 26(02), 3037-3046 3045 5.3. Hybrid Approaches Many modern architectures combine both approaches to leverage their respective strengths. Analysis of large-scale web applications reveals that a significant portion now implement hybrid composition strategies, showing an increasing trend compared to previous years [10]. These hybrid approaches typically implement server-side composition for the initial page shell and critical content, with most hybrid implementations using server-side rendering for the application shell to improve First Contentful Paint while still enabling rich client-side interactivity for the application core. Client-side composition for interactive elements and personalized content remains common in hybrid approaches. Progressive enhancement strategies that work with both models allow graceful fallbacks for less capable devices, with organizations implementing layered enhancement reporting support for more device profiles effectively [9]. Edge workers that enable composition closer to the user have emerged as a powerful hybrid pattern, with implementations leveraging edge computing for composition showing lower latency across global markets and more consistent performance across varying network conditions. 5.4. Decision Framework When evaluating composition strategies, performance requirements and metrics should be clearly defined and weighted. Organizations that establish specific performance budgets before implementation are more likely to achieve their optimization goals [10]. Team structure and governance model significantly impact appropriate composition strategies, with centralized governance models showing greater success with server-side composition, while decentralized teams demonstrate higher productivity with client-side approaches. Technology ecosystem and existing investments shape migration paths, while deployment infrastructure and capabilities directly influence optimal composition models. User device profiles and network conditions often dictate the most suitable approach, with applications targeting emerging markets with limited connectivity showing higher user engagement with server-side composition [9]. Content update frequency and caching requirements affect composition efficiency, while SEO and accessibility requirements remain crucial considerations. Development velocity and team autonomy needs must be balanced with performance requirements to select the most appropriate composition strategy for specific use cases. Figure 4 Micro Frontend Decision Framework [9, 10]