O Superpoder de Cache do React Desbloqueado

Content Delivery Networks (CDNs) formam a base do desempenho web moderno, posicionando estrategicamente o conteúdo em cache geograficamente mais próximo dos usuários. Esta arquitetura distribuída reduz drasticamente a latência, garantindo a entrega rápida de ativos estáticos como imagens, scripts e HTML. Para sites de conteúdo de alto tráfego, aproveitar uma CDN não é meramente uma otimização; é um requisito fundamental para uma experiência de usuário responsiva para públicos globais.

No entanto, uma limitação fundamental assola o cache tradicional de CDNs: a abordagem de "tudo ou nada". As CDNs geralmente armazenam em cache rotas web inteiras, tratando uma URL completa como `/blog/my-post` como uma unidade única e indivisível. Quando um navegador solicita esta rota, a CDN serve a página completa e pré-armazenada de sua localização de borda mais próxima, levando a carregamentos iniciais extremamente rápidos para conteúdo estático.

Esta estratégia de cache monolítica cria um desafio significativo para conteúdo dinâmico. Considere uma página de artigo de notícias com um corpo em grande parte estático, mas uma barra lateral de "Trending Topics" frequentemente atualizada. Se o módulo de tendências é atualizado a cada poucos minutos, todo o cache da página para essa rota deve ser invalidado. Uma atualização menor e localizada em um pequeno componente força a CDN a buscar e armazenar novamente em cache a página completa do servidor de origem, mesmo que 95% do conteúdo principal do artigo permaneça inalterado. Isso leva a uma utilização ineficiente de recursos.

Este ciclo frequente de invalidação leva diretamente a cache misses persistentes. Cada falha ignora a vantagem de velocidade da CDN, forçando a solicitação do usuário a retornar ao servidor de origem, incorrendo em maior latência, aumento da carga do servidor e uma experiência de usuário degradada. Para plataformas com muito conteúdo, onde seções como recomendações personalizadas, anúncios ou feeds de comentários ao vivo são atualizadas constantemente, essas falhas de cache recorrentes anulam grande parte do benefício de desempenho central de uma CDN. O sistema se torna rápido apenas quando o conteúdo é perfeitamente estático, falhando em se adaptar inteligentemente às demandas matizadas de páginas web modernas e interativas. Este paradoxo destaca uma necessidade crítica de um controle de cache granular mais apurado.

React Server Components (RSCs) não são uma panaceia universal para todas as aplicações. Apesar de sua crescente proeminência, particularmente em frameworks como Next.js até 2026, vê-los como uma mudança arquitetônica obrigatória para todo projeto perde seu verdadeiro poder. Essa concepção errônea generalizada frequentemente leva à má aplicação ou, pior, à completa evitação, ofuscando suas capacidades especializadas.

Como Jack Herrington, o "Blue Collar Coder", ilustra com maestria, RSCs não são uma furadeira sem fio de uso geral que você pega para toda tarefa. Em vez disso, pense neles como um adaptador de ângulo reto altamente especializado, projetado para alcançar espaços apertados e difíceis onde ferramentas convencionais simplesmente não cabem. Essa distinção é crucial para entender onde os RSCs realmente brilham.

A analogia de Herrington destaca os RSCs como um instrumento de precisão, construído especificamente para resolver problemas difíceis e específicos que a renderização tradicional do lado do cliente ou mesmo o cache em nível de CDN não conseguem abordar eficazmente. Eles se destacam em cenários que exigem controle granular, onde otimizar o desempenho significa dissecar e gerenciar componentes individuais com precisão cirúrgica. Isso está longe de ser um mandato amplo e de tamanho único.

Considere o desafio do cache granular em sites com muito conteúdo. Embora as CDNs armazenem em cache rotas inteiras de forma eficiente, elas têm dificuldade com seções dinâmicas que exigem atualizações frequentes sem invalidar a página inteira. RSCs fornecem o mecanismo para renderizar e armazenar em cache esses componentes específicos no servidor, permitindo a invalidação de cache independente e entregando conteúdo atualizado precisamente onde e quando é necessário, como uma caixa de "trending topics" que muda rapidamente.

Desbloquear todo o potencial dos RSCs exige uma mudança fundamental de perspectiva. Os desenvolvedores devem adotá-los como uma ferramenta poderosa e de nicho, em vez de um mandato arquitetônico completo para cada aplicação React. Essa abordagem direcionada revela os RSCs como um ativo indispensável para enfrentar desafios complexos de desempenho e gerenciamento de dados, particularmente no domínio da renderização de componentes server-side e entrega eficiente de conteúdo.

As redes de entrega de conteúdo tradicionais (CDNs) são excelentes em servir ativos em cache rapidamente, mas muitas vezes tratam páginas web inteiras como unidades monolíticas. Essa abordagem, embora eficaz para conteúdo estático, torna-se um gargalo significativo para sites de conteúdo dinâmico, como portais de notícias. Uma única página, apesar de seus diversos componentes, recebe uma única entrada de cache e uma política de expiração uniforme.

Considere uma página típica de artigo de notícias. Não é um bloco único e indiferenciado; ela compreende várias zonas de conteúdo distintas, cada uma com requisitos de atualização únicos: - Conteúdo principal do artigo: Raramente atualizado, ideal para cache de até 24 horas. - Cabeçalho/Rodapé: Branding e navegação estáticos, perfeitamente armazenados em cache por uma semana. - Seção de comentários: Moderadamente dinâmica, talvez atualizando a cada hora. - Barra lateral de tópicos em alta: Altamente volátil, exigindo atualizações a cada 5 minutos.

CDNs, por design, armazenam conteúdo em cache com base na URL. Uma requisição para `/articles/react-caching-superpower` resulta em uma única resposta, que a CDN armazena. Consequentemente, você não pode instruir a CDN a aplicar um Time To Live (TTL) de 24 horas ao artigo principal enquanto simultaneamente dá aos trending topics um TTL de 5 minutos naquela mesma URL. Qualquer tentativa de invalidar a seção de trending topics que muda rapidamente forçaria um re-fetch completo da página, anulando os benefícios de armazenar em cache os elementos mais estáveis.

Essa limitação destaca um desafio crítico: alcançar a invalidação de cache independente para seções díspares dentro da mesma rota de página. Aplicações web modernas exigem a agilidade para atualizar apenas os componentes específicos que foram alterados, deixando o restante da página estavelmente armazenado em cache. Para mais informações sobre os fundamentos desses componentes, consulte Server Components - React.

O objetivo final é libertar-se do paradigma de cache tudo ou nada. Ao permitir o controle granular de cache no nível do componente, as aplicações podem entregar conteúdo mais atualizado e relevante onde necessário, sem sacrificar os ganhos de desempenho do cache agressivo de elementos estáticos ou de mudança lenta. Esse cache de precisão aumenta significativamente a experiência do usuário e reduz a carga do servidor de origem.

Uma solução elegante surge ao adotar React Server Components (RSCs) para controle de cache granular, desacoplando meticulosamente o conteúdo na borda. A estrutura central da página, ou "shell", de um site de conteúdo típico — abrangendo elementos como cabeçalhos, rodapés e o conteúdo principal do artigo — é renderizada estaticamente uma vez. As CDNs então servem essa "shell" estável com um TTL (Time-To-Live) longo, potencialmente armazenando em cache por horas ou até dias, garantindo o máximo desempenho global e carga mínima no servidor de origem para as partes mais consistentes da página.

Dentro deste shell de página robusto e de longa duração, regiões específicas exigem atualizações frequentes e independentes. Imagine uma barra lateral de "Trending Topics", um candidato principal para conteúdo dinâmico que se atualiza a cada poucos minutos. Um componente cliente dedicado, incorporado diretamente na página principal durante sua renderização inicial, assume a responsabilidade de buscar e exibir esta seção em rápida mudança. Esta iniciação do lado do cliente garante que o carregamento da página principal permaneça inalterado pela volatilidade inerente do conteúdo dinâmico.

Crucialmente, a requisição de busca do componente cliente não visa um endpoint de JSON API convencional. Em vez disso, ele 'pings' um endpoint de servidor especializado projetado para renderizar *apenas* o componente "Trending Topics" e seus descendentes como um RSC. O servidor executa toda a lógica necessária de busca de dados e renderização para esta seção específica e isolada. Em seguida, ele transmite um flight payload React leve e pré-renderizado—uma representação serializada do DOM virtual—diretamente de volta ao cliente. Esta é uma partida significativa da renderização tradicional do lado do cliente, pois o trabalho de renderização já foi concluído no lado do servidor.

Este endpoint de servidor distinto e sua resposta RSC tornam-se independentemente armazenáveis em cache pela CDN. Ao contrário da duração estendida do cache da página principal, esta resposta RSC recebe seu próprio TTL curto, intencionalmente, talvez apenas alguns minutos ou mesmo segundos, refletindo a rápida frequência de atualização dos tópicos em alta. A adição de uma nova história, por exemplo, pode acionar uma invalidação de cache direcionada para *apenas* o RSC de "Trending Topics", forçando uma nova busca do servidor de origem sem afetar o cache de longa duração da página principal.

Esta arquitetura liberta seções dinâmicas do cache monolítico da página. Conteúdo que se atualiza a cada poucos minutos, como notícias em alta, pode ser atualizado independentemente enquanto o conteúdo circundante, mais estático, permanece altamente armazenado em cache na borda da CDN. Esta estratégia elimina o "paradoxo da CDN" para elementos dinâmicos, entregando simultaneamente conteúdo estático ultrarrápido e experiências dinâmicas atualizadas. A demonstração de Jack Herrington com TanStack Start ilustra poderosamente este desacoplamento, mostrando como um componente cliente solicita um RSC que retorna os dados de voo, que a CDN pode então armazenar em cache com controle granular. Isso não é meramente sobre velocidade; é sobre gerenciamento inteligente de recursos e uma experiência de usuário superior.

Muitos desenvolvedores questionam a necessidade dos React Server Components, perguntando: "Por que uma simples JSON API não é suficiente para conteúdo dinâmico?" Este contra-argumento comum, embora aparentemente lógico, fundamentalmente incompreende os gargalos de desempenho inerentes à renderização tradicional do lado do cliente. Uma arquitetura JSON típica exige que o cliente primeiro busque dados brutos de um endpoint de API, e então execute uma quantidade substancial de JavaScript para analisar esses dados e construir imperativamente os elementos da interface do usuário. Este processo de duas etapas, especialmente a execução de JavaScript do lado do cliente, impõe uma carga computacional significativa.

Essa renderização do lado do cliente acarreta um custo elevado, particularmente em dispositivos móveis ou para UIs complexas e ricas em dados. O thread principal do navegador fica bloqueado, ocupado com o processamento de dados e manipulação do DOM, atrasando o Time-to-Interactive (TTI) e fazendo com que o aplicativo pareça lento. Os usuários experimentam atrasos notáveis antes de poderem interagir com o conteúdo dinâmico, mesmo depois que o conteúdo inicial aparece na tela. Essa penalidade de "hidratação" é um desafio persistente em aplicações de página única.

React Server Components (RSCs) oferecem uma alternativa superior, transferindo o trabalho pesado de renderização para o servidor. Em vez de transmitir dados JSON brutos, o servidor executa a lógica do componente React, buscando os dados necessários e, em seguida, gera um payload de Virtual DOM (VDOM) altamente otimizado. Esses 'flight data', como são conhecidos, representam um conjunto compacto e serializado de instruções para atualizar a UI. Não são apenas dados; são um fragmento de UI pré-renderizado. A demonstração detalhada de Jack Herrington com TanStack Start exemplifica isso, mostrando funções de servidor retornando diretamente esses eficientes flight data para seções dinâmicas como uma barra lateral de "trending topics".

Os benefícios para o desempenho do lado do cliente são profundos. Quando o navegador recebe este payload RSC, seu papel se simplifica drasticamente. Em vez de analisar dados e construir a UI do zero, o runtime React do lado do cliente mescla eficientemente o VDOM pré-renderizado diretamente no Document Object Model (DOM) existente. Este processo ignora a execução extensiva de JavaScript, reduzindo drasticamente a computação e o uso de memória do lado do cliente. O thread principal permanece livre para interações do usuário, levando a um TTI significativamente melhorado. Este pivô arquitetônico não só acelera os carregamentos iniciais da página, mas também garante que as atualizações de conteúdo dinâmico sejam quase instantâneas, proporcionando uma experiência de usuário fluida e responsiva.

React Server Components não são apenas para conteúdo estático ou VDOM pré-renderizado. Seu verdadeiro poder surge ao misturar marcação renderizada no servidor com interatividade do lado do cliente. Um recurso matador permite que um RSC incorpore componentes de cliente, explicitamente marcados com a diretiva `use client`. Esta anotação crucial sinaliza ao bundler que o código incluído requer um ambiente JavaScript para ser executado, ao contrário de seus equivalentes apenas de servidor.

A demonstração de Jack Herrington ilustra vividamente essa capacidade com uma "história interativa". Enquanto histórias básicas renderizam puramente no servidor, uma história interativa inclui um botão "Mais Informações". Clicar neste botão aciona uma caixa `alert()` padrão de JavaScript, confirmando sua natureza do lado do cliente. Esta interação aparentemente simples sustenta uma profunda vantagem arquitetônica.

Crucialmente, o bundle de JavaScript necessário para este componente interativo não está incluído no carregamento inicial da página. Quando o servidor renderiza a página pela primeira vez, ele envia apenas o HTML e o payload VDOM mínimo para a estrutura da história interativa. O JavaScript associado do lado do cliente permanece no servidor, aguardando.

Somente quando o RSC contendo este componente `use client` é renderizado no cliente, seu bundle JavaScript específico é transmitido pela rede. Este mecanismo de entrega sob demanda reduz drasticamente os tamanhos iniciais dos bundles e acelera as métricas de Time to Interactive. Ele incorpora uma forma poderosa de aprimoramento progressivo, garantindo que os usuários recebam conteúdo essencial rapidamente, com interatividade adicionada precisamente quando e onde é necessária.

Este controle granular sobre a entrega de JavaScript vai além de meros ganhos de desempenho. Ele permite que os desenvolvedores construam páginas altamente dinâmicas onde elementos interativos complexos carregam apenas quando um usuário interage com eles, otimizando a utilização de recursos. Para um mergulho mais profundo nessas capacidades dentro de um framework abrangente, explore o TanStack Start Overview | TanStack Start React Docs. Este padrão arquitetônico redefine como as aplicações web modernas gerenciam a interatividade e o carregamento de recursos.

A implementação do TanStack Start dá vida ao conceito de cache de página parcial. No cliente, o componente `TrendingClient` inicia o processo chamando `getTrending` dentro de um hook `useEffect`, buscando dinamicamente os tópicos em alta. Esta chamada do lado do cliente visa uma função de servidor especializada.

`getTrending` Não é um endpoint de API típico; é definido usando `server$.get`, um detalhe crucial para compatibilidade com CDN. Designá-lo como uma requisição GET garante que as Content Delivery Networks possam armazenar em cache sua resposta de forma eficiente, permitindo a entrega rápida do conteúdo em alta. Esta função de servidor atua como o endpoint exposto para o React Server Component (RSC).

Dentro da função de servidor `getTrending`, o mecanismo central é `renderServerComponent(<Trending />)`. Esta API de baixo nível específica do TanStack Start pega o RSC `<Trending />` e o processa no servidor. Em vez de retornar HTML ou JSON bruto, ela serializa o React Virtual DOM do componente em flight data compacto.

O cliente recebe este flight data otimizado, um payload VDOM que inclui tanto a estrutura do componente pré-renderizado quanto qualquer JavaScript necessário do lado do cliente para interatividade. Esta injeção direta de VDOM supera significativamente as APIs JSON tradicionais, que exigem lógica e execução de renderização do lado do cliente. O navegador simplesmente integra a subárvore pré-renderizada, acelerando o desempenho percebido.

Alcançar este controle granular de cache em uma CDN requer uma orquestração cuidadosa além do próprio framework. A demonstração apresenta um sistema personalizado de invalidação de tags, por exemplo, que programaticamente invalida o cache da CDN para o componente de tendências quando novas histórias são adicionadas. Este sistema, embora não integrado ao TanStack Start, destaca as ferramentas e a lógica externas necessárias para gerenciar o ciclo de vida dos RSCs armazenados em cache de forma eficaz.

O vídeo de Herrington, embora demonstre um conceito poderoso, destaca uma visão para o cache granular de página parcial que, até 2026, encontrou em grande parte sua expressão mais madura dentro do ecossistema Next.js. Os React Server Components evoluíram além de sua fase experimental, tornando-se um pilar para aplicações web de alto desempenho, particularmente para sites com muito conteúdo que exigem controle preciso sobre a atualização e entrega de dados. A ferramenta especializada que Herrington defende tem um lar claro e estabelecido.

Next.js se destaca como o líder indiscutível em implementações de RSCs prontas para produção. Sua arquitetura App Router integra profundamente os RSCs, oferecendo aos desenvolvedores mecanismos robustos para renderização no lado do servidor e busca de dados. Crucialmente, o Next.js fornece um Data Cache integrado, memorizando automaticamente as requisições de fetch e oferecendo estratégias sofisticadas de revalidação como `revalidatePath` para rotas inteiras ou `revalidateTag` para segmentos de dados específicos. Isso permite que os desenvolvedores invalidem apenas as porções necessárias de uma página, espelhando o controle granular demonstrado no vídeo, mas com confiabilidade comprovada em batalha.

TanStack Start, conforme demonstrado no vídeo, apresenta uma prova de conceito convincente e com visão de futuro para a integração de RSCs e uso de API de baixo nível. Embora sua abordagem forneça imensa flexibilidade e demonstre as capacidades centrais dos RSCs, ele permanece um framework mais nascente em comparação com o Next.js no que diz respeito à ampla adoção em produção para este padrão de cache específico. O vídeo ilustra efetivamente *o que é possível*, mas o Next.js atualmente oferece uma solução mais completa, integrada e robusta para produção para alavancar RSCs de uma maneira tão sofisticada.

A infraestrutura da Vercel é construída propositadamente para maximizar os benefícios de desempenho das arquiteturas baseadas em RSC, especialmente aquelas alimentadas por Next.js. Sua rede global de edge, juntamente com camadas de caching inteligentes em vários níveis – do CDN às respostas de funções serverless – otimiza perfeitamente a entrega de payloads de RSC. Essa integração estreita garante que os componentes revalidados sejam rapidamente propagados e que os segmentos em cache sejam servidos com latência mínima, suportando diretamente as estratégias de caching complexas e dinâmicas habilitadas pelos RSCs.

Em última análise, a demonstração de Herrington sublinha o valor dos RSCs como um instrumento especializado para desafios intrincados de caching. Embora o exemplo de TanStack Start dissecione brilhantemente a mecânica, Next.js, apoiado pela plataforma otimizada da Vercel, fornece o kit de ferramentas mais abrangente e pronto para produção para implantar esses superpoderes de caching em escala em 2026, capacitando os desenvolvedores a alcançar desempenho e frescor de conteúdo incomparáveis.

O profundo impacto dos React Server Components estende-se muito além dos sites de conteúdo, redefinindo como as aplicações modernas gerenciam desempenho e interatividade através de renderização parcial e caching granular. Essa mudança arquitetônica capacita os desenvolvedores a enfrentar desafios complexos que os mecanismos de caching tradicionais tinham dificuldade em resolver de forma eficiente.

Imagine painéis de business intelligence intrincados, frequentemente carregados com dezenas de widgets interativos. Os usuários normalmente se concentram em alguns selecionados a qualquer momento. Com os RSCs, as aplicações podem adiar o carregamento do JavaScript para widgets inativos, enviando apenas o código interativo necessário quando um usuário interage explicitamente com um componente. Isso reduz drasticamente os tamanhos iniciais dos bundles, acelera o tempo de interatividade e diminui a sobrecarga de hidratação do lado do cliente, otimizando o consumo de recursos mesmo para as interfaces mais ricas em dados.

Plataformas de e-commerce frequentemente realizam A/B tests para otimizar as taxas de conversão, experimentando layouts de produtos, banners promocionais ou botões de call-to-action. Em configurações convencionais, alterar um pequeno componente muitas vezes exige a invalidação de todo o cache da página, anulando os benefícios de desempenho. Os RSCs oferecem uma solução cirúrgica: os desenvolvedores podem trocar variações de teste específicas como componentes de servidor independentes. Isso permite iteração e experimentação rápidas em elementos críticos da UI sem perturbar o cache de longa duração do conteúdo da página circundante, mais estático. Essa invalidação de cache granular garante desempenho contínuo mesmo durante ciclos de teste ativos.

Experiências de usuário logado, ricas em dados personalizados, representam outro candidato principal para este padrão. Considere as seções "Recomendado para Você" ou feeds de atividade personalizados. Uma aplicação pode servir o shell da página abrangente, que permanece em grande parte estático e se beneficia de um longo CDN TTL, enquanto os RSCs buscam e injetam dinamicamente esses segmentos altamente individualizados. Essa estratégia garante que a interface de usuário principal seja carregada instantaneamente do cache, com conteúdo personalizado aparecendo de forma responsiva. Ela minimiza a carga do servidor de origem para ativos estáticos e otimiza a entrega de dados, alcançando um equilíbrio ideal entre caching amplo e personalização individual.

Essa mudança de paradigma em direção ao cache em nível de componente e à hidratação sob demanda abre novas fronteiras para o desempenho da web. Ela transcende as limitações dos caches de página monolíticos, promovendo uma abordagem inteligente e orientada a componentes para o gerenciamento de recursos. Para insights mais aprofundados sobre estratégias avançadas de cache e renderização parcial em frameworks como Next.js, explore recursos como Smarter Caching in Next.js: Partial Rendering and Reusable Components. Esta tecnologia promete desbloquear ganhos de desempenho sem precedentes, otimizando tanto a renderização no lado do servidor quanto a interatividade no lado do cliente em uma vasta gama de aplicações.

Abandone a noção antiquada de armazenar em cache páginas inteiras. A lição fundamental aqui é mudar sua mentalidade para o cache de componentes. React Server Components (RSCs) oferecem a precisão para tratar partes individuais de sua aplicação como unidades de cache distintas, desbloqueando um controle sem precedentes sobre o desempenho.

Este paradigma exige uma reavaliação estratégica da arquitetura da sua aplicação. Considere este padrão RSC centrado em componentes quando: - Uma parte significativa da sua página é mais dinâmica do que o restante, exigindo atualizações frequentes sem perturbar o conteúdo estático. - O tamanho inicial do pacote JavaScript do lado do cliente é uma preocupação crítica de desempenho, pois os RSCs reduzem a necessidade de lógica de renderização do lado do cliente. - Sua estratégia de CDN tem dificuldades com a invalidação granular do cache, incapaz de diferenciar entre seções que mudam rapidamente e conteúdo de longa duração. - Entregar componentes interativos do lado do cliente sob demanda é crucial, evitando sua inclusão no carregamento inicial da página até que sejam necessários.

RSCs não são uma panaceia universal; eles representam uma ferramenta especializada para melhorias cirúrgicas de desempenho. A demonstração de Jack Herrington com TanStack Start ilustra claramente isso, mostrando como uma barra lateral de "trending topics" pode ser armazenada em cache e invalidada independentemente, separada do conteúdo principal do artigo. Este controle granular contorna as limitações típicas de cache em nível de rota de CDNs convencionais.

Aproveitar os RSCs permite que os desenvolvedores visem precisamente os gargalos de desempenho. Você pode servir o esqueleto estático de uma página com um longo TTL de cache da CDN, enquanto elementos dinâmicos como feeds personalizados ou atualizações em tempo real são buscados como payloads RSC leves. Esses payloads contêm VDOM pré-renderizado, levando a uma hidratação mais rápida do que as JSON APIs tradicionais.

Esta evolução no cache não é meramente uma otimização; é uma mudança arquitetônica fundamental. Adotar uma mentalidade de cache centrada em componentes com RSCs representa um grande avanço na construção de aplicações web de alto desempenho, escaláveis e resilientes, especialmente para plataformas de conteúdo em larga escala. Isso capacita os desenvolvedores a criar experiências que são ao mesmo tempo extremamente rápidas e incrivelmente dinâmicas.

O que é cache de página parcial?

Cache de página parcial é a capacidade de armazenar em cache e invalidar diferentes seções de uma única página web de forma independente. Isso permite que o conteúdo dinâmico seja atualizado frequentemente sem afetar o cache de conteúdo mais estático na mesma página.

Por que os RSCs são melhores do que uma JSON API para este caso de uso?

RSCs enviam UI pré-renderizada (VDOM), o que é mais rápido para o cliente exibir. Isso evita o envio de lógica de renderização complexa para o cliente e reduz a computação do lado do cliente, levando a uma renderização mais rápida e melhor desempenho.

Os React Server Components substituem os componentes do cliente?

Não, eles trabalham juntos. RSCs são para lógica apenas de servidor, busca de dados e renderização de UI não interativa. Componentes cliente (marcados com 'use client') são para interatividade, gerenciamento de estado e uso de APIs do navegador.

Posso implementar cache de página parcial sem um framework?

Embora os conceitos centrais façam parte do React, frameworks como Next.js e TanStack Start fornecem a infraestrutura necessária (bundling, roteamento, funções de servidor) que torna a implementação de RSCs e suas estratégias de cache prática.