React: Implantação e CI/CD

Última atualização: 2026-08-26

O blog do Tom funcionava bem localmente, mas, depois de implantá-lo em produção, ele se deparou com todo tipo de problema: as imagens não carregavam, as URLs da API estavam codificadas como localhost e o envio manual de código via SSH era lento e propenso a erros. Ele precisava de um pipeline de implantação automatizado para transformar o processo, desde o envio do código até a produção, em um fluxo de trabalho totalmente automatizado.

Esta aula irá guiá-lo por todo o processo, desde o “desenvolvimento local” até a “implantação em produção”. Você aprenderá a fazer a implantação com um único clique usando o Vercel, configurar um pipeline automatizado com o GitHub Actions, gerenciar variáveis em múltiplos ambientes e otimizar artefatos de compilação para melhorar os tempos de carregamento das páginas. Essas habilidades de implantação são um passo crucial para os engenheiros de front-end na transição de “escrever código” para “entregar produtos”.

1. O que você vai aprender

• Implantação automatizada no Vercel (integração com o Git, configuração de domínio, colaboração em equipe)
• Comparação entre várias opções de implantação: Netlify, Docker e servidores tradicionais
• Configurando um pipeline de CI/CD no GitHub Actions
• Gerenciamento de ambientes (isolamento dos ambientes de desenvolvimento, pré-visualização e produção)
• Desenvolver estratégias de otimização (análise do tamanho dos pacotes, CDN, compactação, armazenamento em cache)
• @next/bundle-analyzer Métodos específicos para visualizar o volume das embalagens
• next/image Como o componente otimiza automaticamente o carregamento de imagens: princípios e configuração

2. Diagramas conceituais

Tom projetou um pipeline completo de CI/CD: quando um desenvolvedor envia código para o GitHub, isso aciona automaticamente os processos de compilação e teste; assim que esses processos são concluídos com sucesso, o código é automaticamente implantado no ambiente de teste para revisão; após a aprovação da revisão e a incorporação do código ao ramo principal, ele é automaticamente implantado no ambiente de produção.

O cerne do pipeline é a automação e a padronização. Todas as etapas de inspeção (verificação de lint, verificação de tipos e testes) são executadas automaticamente no ambiente de CI, sem a necessidade de intervenção manual. Isso garante que quaisquer problemas de qualidade do código sejam detectados antes da fusão, assegurando que apenas o código validado seja implantado no ambiente de produção. A funcionalidade “Preview Deployment” da Vercel gera automaticamente uma URL de pré-visualização separada para cada ramificação, permitindo que gerentes de produto e testadores visualizem os resultados com um único clique.

flowchart LR
    A[Developer Push Code] --> B[GitHub Receive]
    B --> C[GitHub Actions Trigger]
    C --> D{Run CI Process}
    D --> E[Install Dependencies<br/>npm ci]
    E --> F[Code Review<br/>lint / type-check]
    F --> G[Run Test<br/>jest / playwright]
    G --> H[Build<br/>next build]
    H --> I{Deployment Objectives}
    I -->|Feature Branch| J[Vercel Preview<br/>Preview Environment]
    I -->|Main Branch| K[Vercel Production<br/>Production Environment]
    J --> L[Preview URL Automatically Generated]
    K --> M[CDN Distribution<br/>Global Acceleration]

flowchart LR
    A[Developer Push Code] --> B[GitHub Receive]
    B --> C[GitHub Actions Trigger]
    C --> D{Run CI Process}
    D --> E[Install Dependencies<br/>npm ci]
    E --> F[Code Review<br/>lint / type-check]
    F --> G[Run Test<br/>jest / playwright]
    G --> H[Build<br/>next build]
    H --> I{Deployment Objectives}
    I -->|Feature Branch| J[Vercel Preview<br/>Preview Environment]
    I -->|Main Branch| K[Vercel Production<br/>Production Environment]
    J --> L[Preview URL Automatically Generated]
    K --> M[CDN Distribution<br/>Global Acceleration]

3. Um cenário da vida real

A lista de problemas de implantação do blog do Tom não para de crescer: toda vez que ele atualiza uma postagem, precisa acessar o servidor via SSH e executar manualmente git pull, npm run build e pm2 restart — um processo que leva pelo menos 10 minutos. Se ele se esquecer de fazer backup do banco de dados, um único erro pode apagar tudo. O que é ainda mais frustrante é que as alterações feitas por outros membros da equipe frequentemente sobrescrevem o código dele.

Ele decidiu adotar uma solução moderna de implantação usando o Vercel e o GitHub Actions. O primeiro passo foi migrar o código do FTP para um repositório do GitHub; o segundo passo foi conectar-se ao Vercel para habilitar a implantação automatizada; e o terceiro passo foi configurar o GitHub Actions para adicionar verificações de código e fluxos de trabalho de teste. Após a conclusão da migração, toda vez que o código era enviado para o branch main, o Vercel automaticamente compilava e implantava o código, com todo o processo levando menos de 2 minutos.

Tom também comparou os prós e os contras de várias opções de implantação: o Vercel é mais adequado para projetos Next.js e oferece a configuração mais simples; o Netlify também suporta Next.js, mas alguns recursos avançados (ISR, middleware) exigem configuração adicional; a implantação via Docker é adequada para cenários que exigem controle total sobre o ambiente do servidor; e a implantação em servidor tradicional (Nginx + PM2) oferece a maior flexibilidade, mas envolve os maiores custos operacionais. Para blogs pessoais e pequenos projetos, o Vercel é, sem dúvida, a melhor escolha.

(1) Implantação automática no Vercel

O Vercel é uma plataforma de implantação sem servidor oferecida pela Vercel, a empresa responsável pelo Next.js. Ela está profundamente integrada ao Next.js e oferece suporte a todos os recursos do Next.js, incluindo detecção automática de framework, Serverless Functions, Edge Functions, ISR e middleware. O mecanismo de implantação automatizada do Vercel se baseia na integração com o Git — assim que você conecta seu repositório do GitHub, GitLab ou Bitbucket, cada envio (push) aciona automaticamente uma compilação e uma implantação.

O Vercel oferece três ambientes: Produção (ambiente de produção, vinculado a um domínio personalizado), Pré-visualização (ambiente de pré-visualização, com uma URL separada gerada automaticamente para cada branch) e Desenvolvimento (ambiente de desenvolvimento local). O ambiente de Pré-visualização é particularmente adequado para a colaboração em equipe — uma URL de pré-visualização é gerada automaticamente para cada pull request, facilitando aos revisores a verificação de como as alterações ficam em um ambiente ativo.

Etapas de implantação no Vercel (método GUI)

1. Clique em Add New -> Project no painel do Vercel
2. Selecione um repositório do GitHub e autorize o Vercel a acessá-lo
3. O Vercel detecta automaticamente o framework Next.js e utiliza a configuração padrão
4. Adicione as variáveis de ambiente necessárias em “Variáveis de ambiente”
5. Clique em “Implantar” e aguarde cerca de 1 a 2 minutos até que a implantação seja concluída.
6. Assim que a implantação for concluída, o Vercel gera automaticamente o nome de domínio .vercel.app
7. Adicione um domínio personalizado em Configurações -> Domínios

Etapas de implantação no Vercel (método CLI)

# 1. Global Installation Vercel CLI
npm install -g vercel

# 2. Log In Vercel Account
vercel login

# 3. Run the deployment from the project's root directory
# The first time you run it, you'll be guided through the project setup.
vercel

# 4. Deploy to the production environment
vercel --prod

▶ Exemplo 1: Configuração de implantação no Vercel e CLI

# 1. Installation Vercel CLI
npm install -g vercel

# 2. Log in to the project root directory
vercel login

# 3. Deploy the project's root directory to the preview environment
vercel

# 4. Deploy to the production environment
vercel --prod

# 5. View the current deployment status
vercel ls

# 6. View the deployment log
vercel logs --all

// next.config.ts - Vercel Automatically read this configuration
import type { NextConfig } from 'next'

const config: NextConfig = {
  // Image Optimization Settings - Allow remote image domains
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'images.example.com' },
      { protocol: 'https', hostname: '**.cloudfront.net' },
    ],
  },

  // HTTP Compression
  compress: true,

  // Remove X-Powered-By header (security)
  poweredByHeader: false,

  // Custom Build Directory（Optional）
  distDir: '.next',

  // Enable Strict Mode
  reactStrictMode: true,
}

export default config

// vercel.json - Vercel Project Configuration（Optional，Most projects do not require）
{
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "regions": ["hnd1", "iad1"],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

(2) GitHub Actions CI/CD

O GitHub Actions é um serviço de CI/CD oferecido pelo GitHub que utiliza arquivos de configuração YAML para definir fluxos de trabalho. Uma sequência específica de tarefas é acionada automaticamente a cada envio (push) ou solicitação de pull. Tom configurou três tarefas: a primeira executa a verificação de conformidade e de tipos sempre que é feito um envio para qualquer ramificação; a segunda executa testes completos e a compilação quando é feito um envio para a ramificação main; e a terceira faz a implantação automática no ambiente de pré-visualização quando uma nova versão é lançada.

Os arquivos de fluxo de trabalho são armazenados no diretório .github/workflows/, e você pode nomeá-los como quiser. Cada fluxo de trabalho pode conter vários trabalhos, e é possível definir dependências entre eles. O GitHub oferece uma ampla variedade de ações do Marketplace, permitindo que você reutilize diretamente as etapas criadas pela comunidade.

Os conceitos centrais do GitHub Actions incluem: on a definição de eventos desencadeadores (push, pull_request, schedule, etc.), jobs a definição das tarefas a serem executadas, steps a definição das etapas de execução para cada tarefa e actions/ módulos reutilizáveis contribuídos pela comunidade. O fluxo de trabalho do Tom utiliza três ações da comunidade: actions/checkout@v4 (fazer check-out do código), actions/setup-node@v4 (configurar o ambiente Node.js) e actions/upload-artifact@v4 (fazer upload dos artefatos de compilação).

▶ Exemplo 2: Um fluxo de trabalho completo do GitHub Actions

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  # Job 1：Code Quality and Type Checking
  quality:
    name: Code Quality Check
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: TypeScript type check
        run: npx tsc --noEmit

      - name: Lint check
        run: npm run lint

  # Job 2：Run Test + Build
  test-and-build:
    name: Test & Build
    needs: quality  # Dependency quality Mission Successful
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm test
        env:
          CI: true

      - name: Build project
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: next-build
          path: .next/

  # Job 3：Automatically deploy to Vercel
  deploy:
    name: Deploy to Vercel
    needs: test-and-build
    runs-on: ubuntu-latest
    # Only at main Branch Deployment
    if: github.ref == 'refs/heads/main'

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

(3) Desenvolvimento de estratégias de otimização

A implantação é mais do que apenas enviar código para um servidor. Uma configuração de compilação bem otimizada pode melhorar significativamente os tempos de carregamento das páginas e reduzir os custos de largura de banda. Tom dedicou muito esforço à otimização da implantação, concentrando-se principalmente em três áreas: análise do tamanho dos pacotes, otimização de imagens e estratégias de armazenamento em cache.

A análise do tamanho do pacote utiliza o plug-in @next/bundle-analyzer, que permite inspecionar visualmente o tamanho de cada módulo e identificar dependências com tamanhos anormais. Tom descobriu que o moment.js ocupava 85 KB em seu projeto. Após mudar para o dayjs (6 KB), a carga de JavaScript na primeira tela foi reduzida em 28%. Ele também encontrou um componente que nunca havia sido usado, mas que era importado globalmente, então o removeu usando o Tree Shaking.

A otimização de imagens é implementada por meio do componente next/image integrado ao Next.js, que gera automaticamente os formatos WebP/AVIF, tamanhos responsivos e carregamento diferido. A postagem do blog do Tom contém um grande número de imagens; após o uso do next/image, o tempo médio de carregamento das imagens caiu de 1,2 segundos para 0,3 segundos.

A estratégia de armazenamento em cache é implementada por meio da configuração do cabeçalho Cache-Control da CDN. Os recursos estáticos (JS, CSS, imagens) são configurados para um cache de um ano (max-age=31536000), enquanto as páginas HTML são configuradas para um cache mais curto (max-age=60) em conjunto com as atualizações automáticas do ISR. Dessa forma, após a primeira visita de um usuário, os recursos estáticos subsequentes são carregados diretamente do cache do navegador, sem a necessidade de uma nova solicitação.

Referência rápida para outras opções de implantação

▶ Exemplo 3: Criação de uma configuração otimizada

// next.config.ts - Complete Optimization Configuration
import type { NextConfig } from 'next'

// Package Volume Analysis（Enable on Demand）
const withBundleAnalyzer = process.env.ANALYZE === 'true'
  ? require('@next/bundle-analyzer')({ enabled: true })
  : (config: any) => config

const config: NextConfig = {
  // === Image Optimization ===
  images: {
    // Allowed Remote Image Domains
    remotePatterns: [
      { protocol: 'https', hostname: 'images.example.com' },
      { protocol: 'https', hostname: 'cdn.example.com' },
    ],
    // Image Format（Supported by default WebP）
    formats: ['image/avif', 'image/webp'],
    // Equipment Breakpoint（Configure according to the design draft）
    deviceSizes: [640, 768, 1024, 1280, 1536],
  },

  // === Safety and Performance ===
  compress: true,
  poweredByHeader: false,
  reactStrictMode: true,

  // === CDN Layout ===
  // If you use a custom CDN，Settings assetPrefix
  // assetPrefix: 'https://cdn.example.com',

  // === Experimental Features ===
  experimental: {
    // Optimization CSS Volume
    optimizePackageImports: ['antd', '@ant-design/icons', 'lodash-es'],
  },
}

export default withBundleAnalyzer(config)

// vercel.json - Caching and Security Header Configuration
// {
//   "headers": [
//     {
//       "source": "/static/(.*)",
//       "headers": [
//         { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
//       ]
//     },
//     {
//       "source": "/_next/image(.*)",
//       "headers": [
//         { "key": "Cache-Control", "value": "public, max-age=86400, stale-while-revalidate=2592000" }
//       ]
//     }
//   ]
// }

# Commands for Package Volume Analysis
ANALYZE=true npm run build

# This command generates two HTML Report：
# - .next/analyze/client.html (Client-Side Code Analysis)
# - .next/analyze/server.html (Server-Side Code Analysis)

# After opening your browser to view the report,，You can identify and optimize dependencies that are too large.
# Common Optimization Techniques：
# 1. Dynamic Import: const HeavyComponent = dynamic(() => import('./HeavyComponent'))
# 2. Replacing a Large Database: moment → dayjs（Minimize 95%）
# 3. Tree Shaking: import { Button } from 'antd' in place of import { Button } from 'antd/es/button'

Exemplo de otimização: antes e depois

▶ Exemplo 4: Configuração do pipeline de CI do GitHub Actions

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --coverage
      - name: Upload coverage
        if: matrix.node-version == 20
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  build:
    needs: lint-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - name: Check bundle size
        run: |
          SIZE=$(du -sk .next/static | cut -f1)
          echo "Bundle size: ${SIZE}KB"
          if [ "$SIZE" -gt 500 ]; then
            echo "⚠️ Bundle exceeds 500KB threshold"
          fi

▶ Exemplo 5: Abrangente — Configuração completa para implantação do Next.js em produção

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Run tests
        run: npm test

      - name: Build application
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ vars.NEXT_PUBLIC_API_URL }}
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

      - name: Run Lighthouse audit
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            http://localhost:3000
          uploadArtifacts: true
          budgetPath: ./lighthouse-budget.json

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'
          working-directory: ./

      - name: Notify deployment
        if: always()
        run: |
          STATUS="${{ job.status }}"
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H 'Content-type: application/json' \
            -d "{\"text\":\"Deploy $STATUS on $(date -u +%Y-%m-%dT%H:%MZ)\"}"

// lighthouse-budget.json
[
  {
    "path": "/*",
    "options": { "first-contentful-paint": { "maxNumericValue": 2000 } },
    "budgets": [
      { "resourceSizes": [{ "resourceType": "script", "budget": 200 }, { "resourceType": "stylesheet", "budget": 50 }, { "resourceType": "image", "budget": 300 }, { "resourceType": "total", "budget": 600 }] }
    ]
  }
]

❓ Perguntas Frequentes

P: Qual é a diferença entre o Vercel e a implantação tradicional em servidor? R: O Vercel é uma plataforma sem servidor — você não precisa gerenciar servidores, ela se adapta automaticamente, é cobrada por solicitação, oferece aceleração global via CDN e suporta implantações de pré-visualização. A implantação tradicional exige que você adquira seus próprios servidores, instale o Nginx, gerencie certificados SSL e configure o balanceamento de carga. O Vercel é mais adequado para projetos de front-end e full-stack, enquanto a implantação tradicional é mais indicada para cenários que exigem configurações personalizadas de back-end. O plano gratuito do Vercel é mais do que suficiente para projetos pessoais.

P: Como configuro as variáveis de ambiente no Vercel? R: No painel do Vercel, selecione seu projeto -> Configurações -> Variáveis de ambiente. Você pode configurá-las separadamente para cada ambiente (Produção/Pré-visualização/Desenvolvimento). Variáveis com o prefixo NEXT_PUBLIC_ serão incluídas no JavaScript do navegador; variáveis sem prefixo estão disponíveis apenas no lado do servidor. Passe variáveis confidenciais por meio de secrets no GitHub Actions e faça referência a elas por meio de ${{ secrets.XXX }} em seu fluxo de trabalho.

P: O que devo fazer se um teste falhar no processo de CI/CD? R: Por padrão, o GitHub Actions interromperá as tarefas subsequentes se um teste falhar (a tarefa de implantação não será executada). Você pode visualizar os logs de execução do Actions no PR para identificar a causa da falha. Problemas comuns incluem: variáveis de ambiente de teste ausentes, incompatibilidades de versão do Node.js e falhas na instalação de dependências. Recomendamos executar npm test localmente primeiro para confirmar o sucesso antes de fazer o push. Você também pode configurar continue-on-error: true para permitir que a tarefa continue mesmo que certas tarefas falhem.

P: Em quais métricas você deve se concentrar para otimizar a compilação? R: Concentre-se em três métricas principais: tamanho do JavaScript na primeira tela (idealmente <200 KB), pontuação de desempenho do Lighthouse (idealmente >90) e Tempo até o Primeiro Byte (TTFB) (idealmente <200 ms). Use @next/bundle-analyzer para analisar o tamanho do pacote de cada dependência e identificar bibliotecas grandes que possam ser substituídas ou importadas dinamicamente. A otimização de imagens costuma ser a área em que é mais fácil obter melhorias — use next/image para gerar automaticamente o formato WebP e tamanhos de imagem responsivos.

P: O plano gratuito do Vercel é suficiente? Existem limitações? R: O plano gratuito do Hobby inclui: 100 GB de largura de banda por mês, um tempo de execução de 10 segundos por função sem servidor e 1.000 sessões de compilação por mês. Isso é mais do que suficiente para blogs pessoais e pequenos projetos. Principais limitações: as funções sem servidor têm um tempo limite de 10 segundos (60 segundos no plano Pro), operações em lote para atualizações de ISR sob demanda não são suportadas e os links de implantação da versão de pré-visualização expiram após 30 dias. Para projetos comerciais, recomendamos fazer o upgrade para o plano Pro (US$ 20/mês).

📖 Resumo

• O Vercel é a melhor plataforma de implantação para o Next.js, oferecendo suporte à implantação automatizada por meio da integração com o Git, ambientes de pré-visualização, funções sem servidor e uma CDN global
• Os fluxos de trabalho do GitHub Actions são definidos em .github/workflows/*.yml e oferecem suporte à orquestração de várias tarefas e às dependências (needs controla a ordem de execução)
• Processo padrão de CI/CD: Revisão de código → Verificação de tipos → Execução de testes → Compilação → Implantação (cada etapa pode ser realizada em paralelo ou sequencialmente)
• As variáveis de ambiente do Vercel são isoladas por ambiente (Produção, Pré-visualização e Desenvolvimento); as variáveis confidenciais podem ser configuradas por meio do Painel de Controle ou da CLI.
• O conjunto de ferramentas de otimização em três partes: Análise do tamanho do pacote (@next/bundle-analyzer), Otimização de imagens (next/image) e Armazenamento em cache na CDN (Cache-Control)
• dynamic A importação dinâmica e optimizePackageImports podem reduzir efetivamente o tamanho do JavaScript na primeira tela
• A implantação de pré-visualização fornece uma URL exclusiva para cada PR, facilitando a colaboração da equipe nas revisões
• next.config.ts, compress, poweredByHeader, images e outras configurações afetam a segurança e o desempenho
• Opções de implantação: o Vercel é mais adequado para Next.js, o Netlify é mais adequado para sites estáticos, o Docker é mais adequado para projetos em equipe e a implantação tradicional é mais adequada para cenários corporativos
• Valor fundamental do CI/CD: verificações automatizadas da qualidade do código para garantir que apenas o código validado seja implantado no ambiente de produção
• O escopo das variáveis de ambiente é definido pelo prefixo: sem prefixo (lado do servidor), NEXT_PUBLIC_ (lado do navegador), NEXT_PRIVATE_ (declaradas explicitamente no lado do servidor)
• next/image O componente otimiza automaticamente o carregamento de imagens: conversão para os formatos WebP/AVIF, redimensionamento responsivo, carregamento diferido e armazenamento em cache em CDN
• O TTFB, a pontuação do Lighthouse e o tamanho do código JavaScript carregado na primeira tela são métricas essenciais para avaliar a qualidade da implantação

📝 Exercícios

1. Envie seu projeto Next.js para um repositório do GitHub e, em seguida, importe-o para o Vercel (Importar repositório Git). Acompanhe o processo de implantação automatizado e verifique se a URL de pré-visualização e a URL de produção estão corretas após a implantação. Analise os registros de implantação no painel do Vercel para entender cada etapa do processo de compilação. Configure um domínio personalizado (opcional) e habilite o HTTPS.
2. Crie .github/workflows/ci.yml no projeto e configure um fluxo de trabalho de CI: quando um commit for enviado para qualquer branch, execute automaticamente npm ci -> npm run lint -> npm test -> npm run build. Introduza propositalmente um erro de lint ou uma falha no teste e, em seguida, envie as alterações para verificar se a CI falha e exibe uma mensagem de erro. Em seguida, corrija o erro e verifique se a CI é aprovada.
3. Configure a otimização da compilação do projeto: use @next/bundle-analyzer para analisar o tamanho do pacote do projeto atual e identificar as três maiores dependências. Implemente a importação dinâmica para um desses componentes de grande porte (dynamic(() => import(...))) e compare a variação no tamanho do JavaScript antes e depois da otimização. Em next.config.ts, habilite a otimização de imagens (configure remotePatterns) e as configurações de compactação. Por fim, use o Lighthouse do Chrome DevTools para testar as pontuações de desempenho antes e depois da otimização e registre a melhoria no tamanho do JavaScript na primeira tela e nas pontuações de desempenho.

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

Sobre Nós