next super performance

? Performance próximo

Hidratação parcial para o próximo.js com pré -catt x.

---

Explicação: Na primavera, estamos criando sites para jornais e estamos muito, muito cientes do desempenho.

Os jornais são principalmente páginas estáticas. Agora, se criássemos um aplicativo de uma única página, criaríamos um pacote enorme com código desnecessário.

Isso não significa apenas que os usuários esperam que um grande arquivo seja baixado, mas, como Addy Osmami aponta, há um enorme custo de desempenho na análise e execução do código. Como uma vaga regra prática, podemos dizer, quanto maior seu pacote, pior o seu desempenho.

---

É por isso que pretendemos cortar o tamanho do pacote, enviando apenas o código de que realmente precisamos no cliente e deixar o restante para a renderização do lado do servidor.

Visão geral

Esse repartimento ainda é uma prova de conceito, continuaremos a trabalhar nisso e implementar nosso trabalho como 2 pacotes:

• pool-attendant-preact uma biblioteca que implementa a hidratação parcialmente com o PréCT X
• next-super-performance Um plug-in NEXT.JS que usa o Pool-Atendendo-Pré-Pré para melhorar o desempenho do lado do cliente

Além da hidratação parcial, implementaremos estratégias de carregamento, incluindo critical CSS , critical JS , lazy loading , preloading ressources etc. como parte do desempenho próximo.

Documentação

Por enquanto, temos um POC de hidratação parcial para o Next.js e é assim que funciona. Quando você cria um next.config.js e usa nosso plug -in como So

 const withSuperPerformance = require ( "next-super-performance" ) ;
module . exports = withSuperPerformance ( ) ;

2 coisas vão acontecer:

• React será substituído pelo Preact porque é apenas 3kb
• O arquivo JavaScript principal do cliente Next.JS será descartado e substituído por um arquivo JavaScript sob seu controle

Isso significa que você deve criar um client.js na pasta raiz do seu aplicativo que atuará como ponto de entrada para o JavaScript que será enviado ao cliente. Fazemos isso para fornecer controle total do que você deseja que seus usuários baixem e, muito importante, para escolher a estratégia de carregamento adequada para você.

Agora, pool-attendant-preact entra em jogo. Pool-Atendendo-Promete exporta 3 APIs para você:

• withHydration um hoc que permite marcar seus componentes para hidratação
• hydrate uma função para hidratar componentes marcados no cliente
• HydrationData Um componente que escreve adereços serializados para o cliente, como NEXT_DATA

Vamos explicar isso pelo exemplo. Digamos que você tenha um próximo aplicativo com um header , uma seção main e teaser S (que podem ser apenas imagens com um texto e um título, por exemplo). Para o bem deste exemplo, vamos tentar tornar os teasers 2 e 3 dinâmicos (apenas para escolher alguns itens na página) e deixar o restante estático.

Aqui está como você faria isso:

Instale o próximo desempenho

 npm i next-super-performance --save

Crie um next.config.js e use o plug -in

 const withSuperPerformance = require ( "next-super-performance" ) ;
module . exports = withSuperPerformance ( ) ;

Modifique seu package.json para fazer o próximo uso preta corretamente (este alias react ao preact e iniciará os próximos scripts originais sem modificação):

  "scripts" : {
    "dev" : "next:performance dev" ,
    "start" : "next:performance start" ,
    "build" : "next:performance build"
  } ,

Crie pages/index.js

 import Header from "../components/header" ;
import Main from "../components/main" ;
import { HydrationData } from "next-super-performance" ;

export default function Home ( ) {
  return (
    < section >
      < Header />
      < Main />
      < HydrationData />
    </ section >
  ) ;
}

A parte importante aqui é <HydrationData /> que inserirá algo assim:

 < script type =" application/hydration-data " >
  { "1" : { "name" : "Teaser" , "props" : { "column" : 2 } } , "2" : { "name" : "Teaser" , "props" : { "column" : 3 } } }
</ script >

Esses são os nomes e adereços dos componentes que serão hidratados.

Para informar ao seu aplicativo que um componente específico deve ser hidratado withHydration . Nosso main.js poderia ficar assim:

 import Teaser from "./teaser" ;
import { withHydration } from "next-super-performance" ;

const HydratedTeaser = withHydration ( Teaser ) ;

export default function Body ( ) {
  return (
    < main >
      < Teaser column = { 1 } />
      < HydratedTeaser column = { 2 } />
      < HydratedTeaser column = { 3 } />

      < Teaser column = { 1 } />
      < Teaser column = { 2 } />
      < Teaser column = { 3 } />

      < Teaser column = { 1 } />
      < Teaser column = { 2 } />
      < Teaser column = { 3 } />
    </ main >
  ) ;
}

Na linha 4, criamos um componente que será hidratado no cliente e o usamos 2 vezes em nossa página com adereços diferentes.

withHydration preencherá seu componente com um marcador para que possa ser renderizado no servidor e seja encontrado no seu HTML no cliente. Então <HydratedTeaser column={2} /> se tornará

 < Fragment >
  < script type = "application/hydration-marker" />
  < Teaser column = { 2 } />
</ Fragment >

A última e mais crucial parte é o seu client.js . Para um único componente ( Teaser ), pode ser simples assim.

 import { hydrate } from "next-super-performance" ;
import Teaser from "./components/teaser" ;

hydrate ( [ Teaser ] ) ;

Ah, next-super-performance vem com pool-attendant-preact e é por isso que você importa tudo a partir daqui, e não da pool-attendant-preact . Apenas importa e exportações withHydration , hydrate e HydrationData por conveniência.

hydrate encontrará os componentes que você marcou usando withHydration e usará os dados de <HydrationData /> para hidratar -os com os componentes que você passou para eles como uma matriz.

Isso exigirá que você importe os componentes que deseja usar no cliente (e os transmitir para a função hydrate ). Como client.js é o ponto de entrada para todo o código do cliente, isso também significa que você verá e controlará exatamente qual código você enviará para seus usuários. Além de prega, nada mais será enviado.

Se seus componentes tiverem dependências por conta própria, essas dependências também serão enviadas "natuaralmente" porque client.js é sua entrada e cada dependendcy será resolvido através do WebPack.

Status

Este repositório é um POC e algo que vamos construir. Para experimentar, clonar este repositório e depois executar

 # Init Preact Git Sumodule
git submodule init
git submodule update

# Install dependencies
yarn

# Build Preact
cd packages/preact
yarn build

# Build the pool-attendant-preact package
# └─ cd to the pool-attendant-preact dir
cd ...
cd packages/pool-attendant-preact
# └─ build the package
yarn build

# cd to the app dir
cd ...
cd packages/app

# run the app
yarn dev

Conclusão

Esse POC parece funcionar muito bem, poderíamos reduzir drasticamente o tamanho do nosso pacote. Ainda há muito o que fazer. Next.js Still Bundles Código Não queremos ver no cliente (como core-js ). Também pretendemos implementar ferramentas e APIs para criar um idioma para aspectos críticos de desempenho do seu código para fornecer ferramentas para definir seu caminho crítico de renderização.