Os novos compoñentes do servidor de React poderían ser a morte das aplicacións web inundadas

(*Se desexa saltar adiante e mergullarse directamente no desastre técnico, salta a 1.Por que se introduciron os compoñentes do servidor React.)

A principios da década de 2010, React revolucionou o desenvolvemento frontend co seu modelo de compoñentes declarativos e a difusión eficiente do DOM virtual. O que comezou como unha biblioteca de visualización simple pronto converteuse na columna vertebral para aplicacións de páxina única a gran escala (SPAs). Estes SPAs usaron predominantemente Client-Side Rendering (CSR), o que significa que o navegador descargaría un bundle de JavaScript, executalo e construíra a interfaz de usuario enteiramente no cliente.

Este modelo centrado no cliente era flexible e altamente interactivo, e definía aplicacións web "modernas" durante anos. con todo, a medida que as aplicacións crecían máis complexas e ricas en recursos, o enfoque de RSE comezou a mostrar as súas fendas:

que
• Longer Time-to-Interactive (TTI): Os paquetes de JavaScript pesados e o traballo do lado do cliente significaron que os usuarios esperaban máis tempo antes de que puidesen interactuar coa páxina.
que
• Conversión de HTML renderizado por servidor nunha aplicación interactiva (hidratación) converteuse nun punto de choque de rendemento, especialmente a medida que a cantidade de contido dinámico aumentou.
que
• Os paquetes inundados: As aplicacións frecuentemente enviaban moito máis JavaScript do que era necesario, sobrecargando os navegadores con código para funcións ou contidos que poderían ser entregados de forma máis eficiente.
• Desempeño que non se escala: canto máis grande e complexa sexa a aplicación, máis difícil será manter o rendemento rápido en todos os dispositivos e condicións de rede.
que

Next.js emerxeu para abordar algúns destes puntos de dor introducindo Server-Side Rendering (SSR), Static Site Generation (SSG), e outras optimizacións. Estas técnicas melloraron os tempos de carga inicial e descargaron parte do traballo de renderización de UI ao servidor.

Con Next.js 15 executado en React 19, un novo paradigma de renderización tomou o centro da escena:React Server Components (RSC)Os RSC permiten aos desenvolvedores mesturar de forma suave os compoñentes renderizados polo servidor e os renderizados polo cliente nunha única árbore de React. As implicacións son significativas.zero JavaScript overheadNoutras palabras, non é necesaria ningunha hidratación do lado do cliente para esas seccións.A lóxica de captura de datos tamén se simplifica executando os compoñentes do servidor, eliminando moitas chamadas de API innecesarias do navegador.O resultado: bundles máis lixeiros do lado do cliente, interaccións máis rápidas e unha aplicación que é moito máis eficiente e escalable.

Este artigo non é unha revisión a nivel de superficie de RSC. Cando comecei a escribir sobre o uso eficaz de Next.js en 2025, rapidamente quedou claro que React Server Components merecía un mergullo profundo dedicado. O que segue é unha exploración tecnicamente rigorosa de como o RSC funciona baixo o capó, como aproveitalo nun proxecto Next.js 15 e por que representa un cambio fundamental na arquitectura frontend.

Ao final, espero que saia coa mesma claridade e apreciación para RSC que fixen a través do proceso de investigación e escritura desta obra.

Intro: From CSR to RSC — How Rendering Evolved in React

Introdución: De CSR a RSC - Como o rendemento evolucionou en reacción

Ao longo da última década, a forma en que construímos aplicacións de React evolucionou fundamentalmente e, con ela, a forma en que pensamos sobre a renderización.

Unha breve historia de Client-Side Rendering (CSR) en React

React gañou a súa popularidade a través deClient-Side Rendering (CSR)Un modelo onde o navegador descarga JavaScript, execútalo e constrúe toda a interfaz de usuario no cliente.Este enfoque deu aos desenvolvedores un control total sobre a interactividade e o estado, e facilitou a construción de aplicacións dinámicas de páxina única (SPA).

Con todo, a CSR veu con notables compromisos:

que
• Cargas iniciais máis lentas, especialmente en redes móbiles ou pobres
que
• Poor SEO para páxinas orientadas ao contido
que
• Paquetes de JavaScript pesados - mesmo para páxinas con interacción mínima
que
• Foi necesario un paso de hidratación despois de que se cargase HTML, retrasando o tempo de interacción
que

Por un tempo, estas limitacións eran só "como eran as cousas".Entón Next.js cambiou o xogo.

Como Next.js trouxo SSR e SSG ao desenvolvemento de React

candoNext.jsIntroduciu a renderización do lado do servidor (SSR) e a xeración estática de sitios (SSG) como cidadáns de primeira clase para React. Isto marcou un punto de inflexión: os desenvolvedores de frontend agora podían escoller como e cando ocorreu a renderización.

que
• SSR permitiu xerar páxinas por solicitude, mellorando o SEO e a velocidade de carga para o contido dinámico.
que
• SSG permitiu que o contido fose preconstruído no momento da implantación, perfecto para blogs, documentos e sitios de marketing.
que
• A rexeneración estática incremental (ISR) puxo fin á brecha permitindo que as páxinas estáticas se actualizasen despois da implantación.
que

Esta flexibilidade axudou aos desenvolvedores a alcanzar un mellor equilibrio entre o rendemento, o SEO e a experiencia do desenvolvedor.

Pero mesmo con SSR e SSG, aínda había un problema pendente:we were still sending too much JavaScript to the browser- mesmo para compoñentes que non tiñan que ser interactivos.

O aumento dos compoñentes de servidor React (RSC) en 2025

coa liberación deNext.js 15eReact 19Entramos nunha nova era:React Server Components (RSC)Son agora unha parte fundamental de como construímos aplicacións.

A diferenza de SSR, que aínda require hidratación e envía JavaScript ao cliente,RSC allows you to render components on the server — without sending any JavaScript to the browser at all. .

É un gran cambio:

que
• Os compoñentes agora poden acceder directamente aos datos do lado do servidor
que
• O contido estático non require hidratación
que
• Pode mesturar os compoñentes do servidor e do cliente nunha única árbore de React, compondo a súa estratexia de renderización por compoñente
que

RSC non substitúe SSR ou SSG.complements them, desbloqueando un control máis fino sobre o rendemento, o tamaño do paquete e o comportamento de renderización.

En 2025, RSC é un concepto fundamental que todos os enxeñeiros de React deben dominar.

1. Why React Server Components Were Introduced

Por que se introduciron os compoñentes do servidor React

A medida que as aplicacións de React se tornaron máis complexas, a industria comezou a sentir o peso do seu éxito.Mentres que o cliente-side rendering (CSR), servidor-side rendering (SSR) e xeración de sitio estático (SSG) ofreceu estratexias diferentes para construír aplicacións web de alto rendemento, cada un deles levou a cabo compromisos que se tornaron máis evidentes en escala.

Limitacións de CSR, SSR e SSG

1oHydration overhead

Mesmo con SSR ou SSG, unha vez que o HTML alcance o navegador, React necesita "hidratar" a páxina - conectar audiencias de eventos, reiniciar compoñentes e reconstruír efectivamente a aplicación na memoria.

2oJavaScript bundle bloat

Con CSR, cada compoñente, utilidade e chamada de API que forma parte da páxina debe ser enviada ao navegador, independentemente de que sexa interactivo ou non. SSR e SSG reducen isto lixeiramente, pero a maioría do paquete aínda necesita ser executado no cliente.

3oDisconnected data-fetching logic

No mundo pre-RSC, os datos vivían fóra dos compoñentes que os renderizaban.getServerSidePropsougetStaticProps(ou chamar ás APIs enuseEffectEsta separación engadiu sobrecarga cognitiva e fixo que o código fose máis difícil de localizar e reutilizar.

Que problemas RSC foi deseñado para resolver

React Server Components (RSC) foron creados para abordar estes puntos de dor crecentes cunha idea simple pero poderosa:let components execute on the server by default, and only send JavaScript to the browser when it’s absolutely necessary. .

Eliminate unnecessary JavaScript

RSC permite que os compoñentes sexan renderizados do lado do servidorsenSe un compoñente non require interactividade, non hai necesidade de hidratar ou cargar o seu paquete JS.

Server-side data access within the component tree

RSC elimina a fronteira artificial entre a captura de datos e a renderización.async/awaitpara acceder directamente a bases de datos, sistemas de ficheiros ou APIs - co-localizar datos e ver a lóxica de forma natural, sen necesidade de rutas de API ou perforación de prop.

Improve rendering efficiency and developer experience

Ao mover a lóxica non interactiva ao servidor, os desenvolvedores poden construír aplicacións máis lixeiras con paquetes máis pequenos e un mellor rendemento. RSC tamén simplifica o modelo mental - só escribe compoñentes e deixa que o marco manexe onde se executan e como se envían.

RSC non ten como obxectivo substituír SSR ou SSG, senón que os complementa.at the component level, non só o nivel da páxina, sobre o que debe executarse no servidor e o que pertence ao navegador.

In short: React Server Components were designed to bring modern frontend development back to its lean, fast, and maintainable roots without compromising interactivity.

2. Rendering Strategies in Next.js 15: RSC vs SSR vs CSR

Estratexias de rendemento en Next.js 15: RSC vs SSR vs CSR

Next.js 15 ofrece aos desenvolvedores un modelo de renderización granular que vai moito máis alá das estratexias tradicionais a nivel de páxina.React Server Components (RSC)Para converterse nun concepto de primeira clase, é esencial entender como se comparan con dous modelos coñecidos:Server-Side Rendering (SSR)eClient-Side Rendering (CSR). .

Aínda que SSG (xeración de sitios estáticos) aínda é valioso en casos específicos, pódese ver como uncaching strategyconstruído sobre a base da SSR. En contraste,RSC vs SSR vs CSR represent distinct runtime rendering paths, and understanding them is crucial for making performance- and architecture-aware decisions in 2025.

💡 Antes de comparar: que queremos dicir por "compoñente interactivo"?

No contexto de React e Next.js, unhainteractive componentCalquera elemento querequires client-side JavaScript to respond to user input or browser events. .

Isto inclúe (pero non está limitado a):

que
• Botóns que actualizan o estado en clic
que
• Formularios con entradas de validación ou controladas
que
• Dropdowns e modals que cambian aberto / pechado
que
• Animacións desencadeadas por scrolling ou hover
que
• Tabs, carrozas, filtros e slides
que
• Compoñentes que usan useState, useEffect ou useReducer
que

Se un compoñente tenevent handlers→ Internostateou confiar na súaDOM or browser APIsDebe correr sobre o cliente.

Interactivity = Browser-side behavior + JS event listeners + local state.

Comprender esta distinción axuda a aclararwhy RSC exists: para evitar o envío de JavaScript para pezas de interface que non teñan que ser interactivas.

Rendering modelos a unha ollada

queFunción RSC (React Server Components) SSR (Server-Side Rendering) CSR (Client-Side Rendering) Render location Server Server Client JavaScript enviado ao navegador 🔸 None ✅ Si ✅ Si Require hidratación 🔸 Non ✅ Si ✅ Si Interactividade 🔸 Non ✅ Full ✅ Full Access to server resources ✅ Direct ✅ Via getServerSideProps 🔸 Necesita chamadas API Cando se executa On-demand ou Streamed Per request On load in browser Ideal case use Estática ou datos-bound views Personalizado ou dinámico UI Fluxos interactivos, local UXCaracterísticas RSC (Compoñentes do servidor de reacción) SSR (Rendering do lado do servidor) CSR (Rendering do lado do cliente)quequeEnviar localizaciónqueServizosqueServizosqueclientequequeJavaScript enviado ao navegador Ningún ✅ Si ✅ SiqueRequire hidratación Non ✅ Si ✅ SiqueInteractividade Non ✅ Completo ✅ CompletoqueAcceso aos recursos do servidor ✅ Directo ✅ A través de getServerSideProps ❌ Necesita chamadas de APIqueCando se executa On-demand ou transmitido por petición En carga no navegadorqueCaso de uso ideal Visións estáticas ou baseadas en datos UI personalizado ou dinámico Fluxos interactivos, UX localqueCaracterísticas RSC (Compoñentes do servidor de reacción) SSR (Rendering do lado do servidor) CSR (Rendering do lado do cliente)Características

Características

RSC (compoñentes de servidor de reacción)

RSC (compoñentes de servidor de reacción)

que

SSR (Server-Side Rendering)

SSR (Rendering ao lado do servidor)

CSR (Rendering do lado do cliente)

CSR (Rendering do lado do cliente)

queEnviar localizaciónqueServizosqueServizosqueclientequeEnviar localización

Enviar localización

que

Servizos

Servizos

Servizos

Servizos

cliente

cliente

JavaScript enviado ao navegador Ningún ✅ Si ✅ SiJavaScript enviado ao navegador

JavaScript enviado ao navegador

Ningunha

Ningunha

que

Si

Si

que

Si

Si

Require hidratación Non ✅ Si ✅ SiRequire hidratación

Require hidratación

non

Non

Si

Si

Si que

Si

Interactividade Non ✅ Completo ✅ Completoque

Interactividade

Interactivity

que

Non

❌ No

que

✅ Full

Unha chea

que

Unha chea

Unha chea

Acceso aos recursos do servidor ✅ Directo ✅ A través de getServerSideProps ❌ Necesita chamadas de APIAcceso aos recursos do servidor

Acceso aos recursos do servidor

Directamente

Directamente

✅ A través de getServerSideProps

✅ A través de getServerSideProps

Precisa de chamadas API

Precisa de chamadas API

Cando se executa On-demand ou transmitido por petición En carga no navegadorcando se corre

cando se corre

On Demand ou Streamed

On-demand or streamed

Por petición

Por petición

que

Descargar en Browser

Descargar en Browser

Caso de uso ideal Visións estáticas ou baseadas en datos UI personalizado ou dinámico Fluxos interactivos, UX localCaso de uso ideal

Caso de uso ideal

que

Visións estáticas ou baseadas en datos

Visións estáticas ou baseadas en datos

que

UI personalizado ou dinámico

UI personalizado ou dinámico

Fluxos interactivos, UX local

Fluxos interactivos, UX local

Think in Components, Not Just Pages

Nas versións anteriores de Next.js, as estratexias de renderización aplicáronse napage level. You had getServerSideProps,getStaticPropsCalquera que sexa a súa elección aplicada aoPáxina completaIsto fixo sentido nun mundo onde a renderización ocorreu todo ou nada - xa sexa estáticamente no tempo de construción, ou dinámicamente en cada solicitude.

Pero conReact Server Components (RSC)e oapp/directorio introducido en Next.js 13+ e estandarizado en 15,rendering is no longer a top-down, one-size-fits-all decisionconverteuse en aper-component concernIsto desencadea unha nova mentalidade.

🧠 A New Way of Thinking: Declarative and Composable Rendering

Este cambio é máis que un cambio de API, é un cambio conceptual na forma en que arquitecta o seu frontend.

Declarative

No canto de orquestracióncomoeondeos compoñentes son renderizados manualmente, agora simplementedeclare what each component does and what it needs— React e Next.js coidan do resto.

Non transmite props de SSR a compoñentes, nin transmite props manualmente a puntos finais de API.

// Server Component
export default async function ProductInfo() {
  const product = await db.getProduct(slug)
  return <div>{product.name}</div>
}

Este compoñente:

que
• Runs on the server
que
• Non envíe JS ao cliente
que
• Non require ningún getServerSideProps ou capa de API
que
• É "só un compoñente" - non é necesaria ningunha abstracción adicional
que

Describe a UI e as súas necesidades de datosdeclaratively, e o motor de renderización calcula o resto.

Composable

Diferentes partes da súa interfaz de usuario poden usar diferentes estratexias de renderización.on the same page,at the same time, ewith minimal overhead. .

Por exemplo:

// Product page layout
<ProductInfo />           // Server Component (no JS, rendered on the server)
<AddToCartButton />       // Client Component (interactive)
<SimilarProducts />       // Static Component (SSG with revalidation)

Estes compoñentes viven xuntos na mesma árbore, pero cada un:

que
• Executa nun ambiente diferente (servidor, cliente, construír)
que
• Utiliza só os datos e o código que necesita
que
• Navega exactamente o que se require para o navegador - non máis, non menos
que

Para facelo máis sinxelo, fixemos unhaDemo mínimoque mostra como diferentes estratexias de renderización poden coexistir nunha única páxina.

3. How React Server Components Work Under the Hood

3. How React Server Components Work Under the Hood

React Server Components (RSC) son máis que unha nova estratexia de renderización, cambian fundamentalmente como se constrúen, renderizan e transmiten as árbores de compoñentes.how it works behind the scenese como afecta ás fronteiras de estado, interactividade e datos.

Fronteira de servidor/cliente: unha árbore de reacción dividida

As aplicacións de reacción que usan RSC xa non se renderizan completamente no cliente.component tree is split into two worlds: de

que
• Compoñentes do servidor: só se executa no servidor. Nunca se envía JavaScript ao navegador. Non se pode manter o estado local ou anexar auditorios de eventos. Perfecto para renderizar contido estático e lóxica vinculada ao servidor (por exemplo, acceso DB).
• Compoñentes do cliente: Deben estar explicitamente marcados con "Use client".Estes compilados en JavaScript amigable ao navegador e soportan a interactividade completa, o estado local, o usoEffect e a xestión de eventos.
que

En build ou runtime, React constrúe unha árbore onde os compoñentes do servidor e do cliente coexisten e as une durante a renderización.

---

📍 What "use client"En realidade fai

When you add "use client"a un ficheiro, marca que todo o módulo e as súas exportacións comoclient-onlyDetrás das escenas, isto instrue ao Next.js construír a pipeline para:

• Compila ese ficheiro (e as súas dependencias) nun bundle separado de JavaScript
que
• Exclúe ese compoñente de ser executado no servidor
que
• Treat it like a classic React CSR component with hydration logic

Esta directiva actúa como unhaboundary marker between the two sides of the tree. All components above it can be server-rendered; all components below it must be rendered in the browser.

💧 Streaming: Rendering in Pieces, Not All at Once

RSC abrazosstreamingcomo unha estratexia de renderización nativa. en lugar de esperar a que se construíse a árbore de React completa antes de enviala ao navegador, o servidorstreams serialized fragmentsdo usuario ao cliente cando estea preparado.

que
• Compoñentes do servidor son renderizados e enviados o máis axiña posible
que
• Lugares (por exemplo, a través de <Suspense>) para cubrir temporalmente
• Os compoñentes do cliente hidratan incrementalmente, só cando se cargan
que

Como é posible isto?

RSC introduce un concepto chamado hidratación selectiva. Cando un Compoñente do Cliente é renderizado dentro dunha árbore do Compoñente do Servidor, React inserta un detentor de lugar (<div data-rsc-placeholder />) e desvía a hidratación.

Unha vez que o cliente cargou o bundle JS correspondente:

que
1. React lazily carga ese compoñente específico
que
2. Atopa o carpinteiro e séguelle á árbore viva
que
3. Hidrata-lo en illamento, sen re-render toda a páxina
que

This design is decoupled and progressive: your app starts fast, and interactivity comes online gradually.

<Suspense fallback={<LoadingDetails />}>
  <ProductDetails />  // Server Component
</Suspense>

<AddToCartButton />    // Client Component (hydrated later)

Recuperación de datos e división de código en RSC

Outra clave “máxica” de RSC:you can fetch data directly inside components withqueasync/awaitsen depender degetServerSideProps,useEffectou de paso manual.

// Server Component
export default async function Dashboard() {
  const stats = await getStatsForUser()
  return <StatsView data={stats} />
}

Por que isto é posible?

que
• Os compoñentes RSC funcionan como funcións de servidor reais, non como módulos compilados polo cliente
• Poden acceder a bases de datos, APIs internas, sistemas de ficheiros ou a calquera cousa que soporte o seu tempo de execución do servidor
que
• O resultado é renderizado en HTML (non JS) e transmitido ao cliente
que

E tamén:

que
• Non é necesaria hidratación, xa que o resultado é estático
que
• Non hai lóxica de UI de carga no propio compoñente - todo se resolve antes de que chegue ao navegador
que
• No code for this component is sent to the client — unless nested inside a client boundary
que

Isto reduce significativamente o tamaño da caldeira e do paquete, mantendo a lóxica colocada coa interface de usuario - un obxectivo de longa data de React que finalmente se realizou a escala.

Estado, ganchos e consideracións do ciclo de vida

RSC does not supportReaccións tradicionais comouseState,useEffectouuseRef, because they don’t run in the browser. .

queCompoñente de servidor Compoñente de clientequequeO efectoqueusoContexto ✅ (se estático) ✅queasync/await ✅ (debería envolverse en efectos)Xogadores

Utilización

Compoñente de servidor Compoñente de clientequeUtilizaciónqueO efectoqueusoContexto ✅ (se estático) ✅queasync/await ✅ (debería envolverse en efectos)XogadoresCompoñente de servidor Compoñente de cliente

Características

Feature

Server Component

Server Component

que

Compoñentes do cliente

Client Component

queUtilizaciónquequeUtilización

useState

❌

que

✅

✅

O efecto

useEffect

useEffect

que

✅

✅

usoContexto ✅ (se estático) ✅Utilización do contexto

useContext

✅ (se é estático)

✅ (se é estático)

que

✅

queque

async/await

queque

(debería envolverse en efectos)

que

async/await

async/await

que

(debería envolverse en efectos)

(debería envolverse en efectos)

Xogadoresque

Traballadores de eventos

Traballadores de eventos

que

✅

✅

Isto impón unha clara separación de responsabilidades:

que
• Compoñentes do servidor: datos e deseño
• Compoñentes do cliente: interactividade e estado local

---

Os Compoñentes do servidor de React están deseñados para simplificar a túa aplicación. Unha vez que internalizas as regras de límite, o modelo de transmisión e o acceso de datos asínc, podescompose fast, personalized, and minimal-JS appscon moito menos carballo que antes.

4. What’s the Best Practice? Combining RSC, SSR, and SSG

4. What’s the Best Practice? Combining RSC, SSR, and SSG

Unha das preguntas máis comúns que enfrontan os enxeñeiros de React en Next.js 15 non é "debe usar RSC?" - é“how do I combine RSC with SSR and SSG in a maintainable, high-performance way?”

A beleza de Next.js 15 é que xa non está limitado a unha estratexia de renderización por páxina.compose rendering strategies at the component level, applying the most appropriate approach to each part of the UI.

This section introduces a practical framework for making that decision based on actual architectural needs.

Comezar coa pregunta principal: que necesita este compoñente?

Fai estas catro preguntas para cada compoñente:

que
1. Does it need to be interactive?
   • ✅ Yes → Use a Client Component
2. Does it need secure, request-specific, or real-time data?
   • ✅ Yes → Consider SSR
3. Pode ser precomputado ou actualizado con pouca frecuencia? ✅ Si → Prefer SSG
que
4. Recolle datos do servidor pero nunca necesita executarse no cliente? ✅ Si → Use RSC
que

Exemplo: Estratexia de desintegración da páxina de produto

Aquí está como unha páxina de produto de comercio electrónico típica podería ser composta usando todas as tres estratexias:

queCompoñente Rendering Estratexia Razón ProdutoDetalles RSC Obtido de DB, sen interactividade, sen necesidade de hidratar PriceWithPersonalization SSR Depende da sesión do usuario, dinámico por solicitude AddToCartButton CSR Require interactividade e estado local RelacionadosProductos SSG (con ISR) Seguro para cache no tempo de construción, pode revalidar cada 24h ou por tag StockStatusBanner RSC + streaming Frecuentemente cambiante, transmitido con Suspensión para non bloquear TTFBCompoñente Rendering Estratexia RazónDetalles do produto RSC recuperado de DB, sen interactividade, sen necesidade de hidratarqueSSR de personalización Depende da sesión do usuario, dinámico por solicitudeque

AddToCartButton

queCSRqueque

Require interacción e estado local

queProdutos SSG (con ISR) Seguro para cache no tempo de construción, pode ser revalidado cada 24 horas ou por etiquetaquequeAcciónsBannerqueRSC + reproduciónqueCambiar con frecuencia, transmitido con Suspense para non bloquear TTFBquequeCompoñente Rendering Estratexia Razónque

Compoñentes

Compoñentes

Realización dunha estratexia

Rendering Strategy

que

Razóns

Reason

Detalles do produto RSC recuperado de DB, sen interactividade, sen necesidade de hidratar

ProductDetails

ProductDetails

RSC

RSC

Tirado de DB, sen interactividade, sen necesidade de hidratar

Tirado de DB, sen interactividade, sen necesidade de hidratar

SSR de personalización Depende da sesión do usuario, dinámico por solicitudeque

PrezoPersonalización

PriceWithPersonalization

SSR

SSR

que

Depende da sesión do usuario, dinámico por solicitude

Depende da sesión do usuario, dinámico por solicitude

AddToCartButton

queCSRqueque

Require interacción e estado local

AddToCartButton

AddToCartButton

CSR

CSR

que

Require interacción e estado local

Require interacción e estado local

Produtos SSG (con ISR) Seguro para cache no tempo de construción, pode ser revalidado cada 24 horas ou por etiquetaque

Produtos relacionados

RelatedProducts

que

SSG (with ISR)

SSG (with ISR)

que

Seguro para caché durante a construción, pode ser revalidado cada 24 horas ou por tag

Safe to cache at build-time, can revalidate every 24h or per tag

queAcciónsBannerqueRSC + reproduciónqueCambiar con frecuencia, transmitido con Suspense para non bloquear TTFBqueAcciónsBanner

StockStatusBanner

RSC + reprodución

RSC + streaming

Frequently changing, streamed in with Suspense to not block TTFB

Frequently changing, streamed in with Suspense to not block TTFB

Each component is doing just what it needs to doNon hai hidratación de páxina completa, non hai captura de datos globais, non hai JavaScript innecesario.

📐 Design Best Practices for Combining Strategies

✅ 1.- Comezar o servidor primeiro

En canto ao número de páxinas web, inclúese o número de páxinas web que inclúen todas as páxinas ("use client") only when necessary. This keeps bundles smaller and simplifies testing.

2.- Manteña os límites claros

Use nomes de cartafol ou sufixos de nome de ficheiro para que os límites sexan explícitos:

/components
  /server/ProductDetails.tsx
  /client/AddToCartButton.tsx
  /shared/ReviewStars.tsx

✅ 3. abrazar suspensión para entrega progresiva

Utilización<Suspense> to stream in non-critical RSCs without blocking the whole page:

<Suspense fallback={<LoadingReviews />}>
  <ReviewList />
</Suspense>

Co-locate lóxica con compoñentes

Non divida a captura de datos e a interfaz de usuario entre ficheiros a menos que sexa necesario.asynclóxica directamente dentro da árbore de compoñentes - o marco coida do resto.

✅ 5. Use ISR (Incremental Static Regeneration) smartly

Para páxinas cacheables con alto tráfico, como artigos de blog ou seccións de marketing, use SSG + revalidación:

export const revalidate = 3600  // regenerate every hour

6 erros comúns a evitar

que
• ❌ Using "use client" by default — you’ll end up with CSR all over again
que
• Recuperación de datos nos compoñentes do cliente cando podería ser recopilado polo servidor
• ❌ Passing too much data between RSC and client components via props — instead, let client components be focused, isolated, and stateful
que
• Recreación de SSR-estilo getServerSideProps lóxica dentro de RSC - non hai necesidade, RSC é servidor-side

✅ Decision Tree Summary

Velaquí unha guía simplificada:

Is it interactive?
│
├── Yes → Client Component (CSR)
│
└── No
    │
    ├── Needs per-request data? → SSR
    │
    ├── Can be pre-rendered? → SSG
    │
    └── Otherwise → RSC

Non tes que memorizalo.Unha vez que internalizas como renderizar mapas á responsabilidade,the decisions become intuitive. .

A mellor práctica non é sobre escoller "a mellor estratexia de rendemento".

It’s aboutdesigning rendering as an intentional part of your component architecture- Con claridade, propósito e rendemento en mente.

6. Looking Ahead: Why RSC Is More Than Just a Feature

Mirando cara adiante: por que RSC é máis que unha característica

Os compoñentes do servidor React non son só unha optimización de rendemento ou unha mellora de DX.they represent a foundational shift in how we build React applications. Much like React Hooks in 2019, RSC in 2025 is redefining the baseline for frontend architecture. .

RSC cambia o modelo mental da construción en reacción

O desenvolvemento tradicional de React sempre se construíu sobre esta suposición:

“The browser owns the runtime. We hydrate everything. Every piece of logic and data must live in the client, or be fetched via API.”

RSC breaks that assumption.

Con RSC, agora preguntas:

que
• Podo saltar a hidratación por completo?
• Pódese executar este compoñente puramente no servidor?
• Podo colocar a lóxica de backend coa miña UI?
que

It gives us back the ability to separate display logic and interactivity cleanlypero non con castañas e castañas, senón confirst-class architectural boundaries. .

Xa non é “client-first”.“purpose-first.”

Cada parte da súa interfaz de usuario existe onde é máis eficiente: servidor, cliente ou estático.

🌐 Ecosystem Shift Toward Server-First Rendering

RSC isn’t happening in isolation. The broader frontend ecosystem is undergoing a server-first rendering renaissance. .

Frameworks como:

que
• Remix inclínase fortemente na carga de datos do servidor e nas accións de formulario.
• Astro embraces zero-JS by default, shipping only islands of interactivity.
que
• Qwik leva a hidratación ao extremo - adiando todos os JS ata que sexa explícitamente necesario.
• Next.js 15, con RSC e App Router, agora pon a renderización por compoñente no centro da experiencia do desenvolvedor.
que

Esta non é unha coincidencia, é un reflexo dunha dura verdade que todos sentimos:

Sending less JavaScript is the only way to scale interactivity and performance on the modern web.

Os compoñentes do servidor React son a resposta nativa de React a ese desafío - profundamente integrados, ergonómicos e listos para a produción.

O que esperar a continuación

A medida que React 19 e o ecosistema maduran, podemos esperar:

• Máis ferramentas de depuración e perfilado granular para árbores RSC
que
• Mellor integración de DevTools para mostrar límites e tempos de hidratación
que
• Patróns de orde superior a estratexias de rendemento abstracto (por exemplo, <ServerOnly>, <DeferredClient> envases)
que
• Adopción máis ampla en sistemas de deseño, frameworks e bibliotecas (por exemplo, kits de UI RSC-aware)
que

---

Gústache a lectura?

Se este artigo axudou a pensar doutro xeito sobre React e Next.js

Follow me on HackerEditarPara máis profundidades

HackerEditar

Or connect with me on ligazónspara falar sobre React, arquitectura ou migración RSC

ligazóns