Toss Bank Decides to Postpone App Router Adoption: Migration Costs Outweigh Benefits

Toss Bank's frontend team reviewed the adoption of Next.js App Router and RSC (React Server Components) and decided to postpone implementation and retain Pages Router due to insufficient benefits relative to stability maintenance costs. In the fall of 2025, a tech group was formed to conduct migration experiments on actual services, summarizing key issues and conclusions as follows.

Streaming Rendering and Layout Stability

Verification of Suspense-based streaming rendering revealed First Contentful Paint (FCP) delay issues in WebKit environments. Initial FCP was 5,065ms, which could be improved to 103ms by inserting invisible SVGs. However, Cumulative Layout Shift (CLS) issues arose due to height differences between skeletons and actual content. While optimizing skeleton heights reduced CLS from 0.138 to 0.036, the burden of managing loading screens per section increased, leading to the judgment that layout stability management costs outweighed the benefits of streaming rendering.

RSC Utilization and Bundle Optimization

Using RSC allowed for bundle size reduction by implementing server components and excluding dependencies from client bundles, as well as simplifying data loading code by integrating authentication logic via the headers() API. Separating RSC and client implementations through conditional exports in package.json improved the development workflow. However, due to extensive browser interactions (buttons, inputs, app bridges, etc.), the proportion of Client Components was high, making it essential to distinguish boundaries between server and browser code and verify common packages across execution environments. In particular, environment compatibility checks were necessary, as app bridge calls were silently ignored without errors in server components.

Migration Operational Issues

When running Pages Router and App Router in parallel, navigation broke in specific path structures. With basePath configured, navigating between Pages Router screens resulted in duplicate basePath application in the path, causing 404 errors. Additionally, due to issues with the registration method of the Bloom Filter used by the client router to determine if a screen is an App Router screen, the /a/[id] pattern was registered as /a, causing the Pages Router address /a/a to match every time. Separate work was required to replace existing features, such as providing path patterns for logging and removing router.events, leading to the conclusion that these migration and operational costs exceeded the benefits.