Categorias
AMP Accelerated mobile pages

Criando primeira página AMP

Novo curso em meu canal do YouTube sobre AMP já está no ar:

Nos primeiros vídeos e posts eu fiz a apresentação do nosso projeto. Agora vamos aprender a criar nossa primeira página e ver quais os requisitos básicos para publicar nossa primeira página válida.

Requisitos básicos

  1. Primeiro precisamos sinalizar que temos conteúdo AMP através de um emoji de raio ou adicionando a palavra AMP em nossa tag HTML
  2. Carregar o script da biblioteca
  3. Utilizar ferramentas como validador para deixar nossa página 100% compatível

AMP validator

O validator é importante por duas razões:

  1. Manter a qualidade do seu código como acessibilidade e performance
  2. Somente conteúdo válido será entregue pelo AMP cache
  3. Não fique desmotivado caso tenho uma série de erros de validação isso é um sinal que você terá uma série de melhorias em seu código

Para utilizar o Validator você pode utilizar 4 versões:

Vamos utilizar um simples código HTML para fazer nossa primeira conversão, para ativar o validator precisamos adicionar o atributo amp na tag Para validator reconhecer o conteúdo adicionamos em nossa tag HTML o parâmetro amp:

<!DOCTYPE html>
<html amp>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,minimum-scale=1">
    <meta name="description" content="nossa primeira página amp">
  <head>
    <title>Como validar uma página AMP</title>
  </head>
  <body>
    Olá AMP
  </body>
</html>

Quando testamos o código acima no validator web temos o seguinte retorno:

web validator

No caso esteja utilizando a extensão Chrome o retorno será através de um ícone no topo superior direito.

AMP Cache

AMP cache é utilizado por mecanismos de busca como Bing e Google eles realizam o preload da primeira página de sua aplicação assim realizando o carregamento quase que instantâneo de sua aplicação.

O cache realiza optimização automática de sua aplicação com:

  • Cache images e fonts
  • Comprime images
  • Converte images em formatos como Webp caso o browser suporte
  • Limpeza do HTML para prevenir ataques XSS

Anatomia de uma página AMP

Todas as páginas AMP iniciam com o mesmo código base com requisitos obrigatórios:

  • Atributo AMP na tag html
  • viewport tag
  • Chamada para o JavaScript da biblioteca
  • Boilerplate CSS

Esse código é chamado de AMP boilerplate, podemos gerar o nosso código boilerplate através da página amp.dev/boilerplate lá podemos realizar uma série de configurações em nosso código base, chamada de fontes, suporte a service worker, SEO e Google Analytics:

Tela de configuração do amp boilerplate

Como vimos na validação anterior apenas um markup básico não é suficiente para criar uma página válida. Aplicando as regras que vimos anteriormente a nossa estrutura básica ficará da seguinte forma:

<!DOCTYPE html>
<html amp>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,minimum-scale=1">
    <meta name="description" content="Este é um Boilerplate AMP.">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>Como validar uma página AMP</title>
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <link rel="canonical" href=".">
  </head>
  <body>
    Olá AMP
  </body>
</html>

Agora temos uma versão válida, como qualquer arquivo HTML uma página AMP precisa de uma tag head e tag body. Mas com uma atenção a três items. A script tag que carrega o script da biblioteca, canonical tag que iremos entrar em detalhes posteriormente e uma tag stile com o CSS boilerplate. Com isso temos o seguinte resultado:

Canonical tag

Um dos pré requisitos para ter uma página válida é a tag canonical ela é responsável por informar se conteúdo carregado possui uma versão não AMP, para o mecanismos de busca não identificar sua página AMP como conteúdo duplicado. Caso possua apenas a versão AMP aponte para própria página. em nosso caso na linha 11 definimos nossa propriedade com “.”

Viewport meta responsável por definir como sua aplicação vai responder visualmente a múltiplos devices. Na linha 10 temos o CSS responsável por esconder o conteúdo da página enquanto a aplicação é processada pelo JavaScript. Você não precisa editar esse arquivo mantenha do jeito que copiar.

Por fim temos o carregamento do JS da biblioteca, a primeira tag “link” na linha 7 é responsável por realizar o preload do script e na linha seguinte tag “script” realiza o carregamento detalhe para async dentro da tag ele determina que nosso script será carregado de forma assíncrona.

CSS

Ok, temos nosso markup básico mas caso queiramos carregar um arquivo CSS teremos um seguinte erro no validator:

Mensagem não ajuda muito mas isso significa que a tag link com AMP só é válida para fonts e além disso para um set específico de fontes:

  • Fonts.com: https://fast.fonts.net
  • Google Fonts: https://fonts.googleapis.com
  • Font Awesome: https://maxcdn.bootstrapcdn.com
  • Typekithttps://use.typekit.net/

No caso do style customizado teremos que adicionar de forma Inline, isso é um requisito para reduzir o número de requisições e também ajudar no cache de sua aplicação. Além disso ele precisa ser adicionado em uma tag <style amp-custom> e os requisitos são os seguintes

  • 50kb por tag
  • Somente uma tag por página
  • O uso de !important é totalmente proibido
  • Seletores CSS não podem começar com ‘-amp-‘

O projeto usado no curso está no repositório: https://github.com/fellyph/the-best-caipirinha/ as aulas serão separadas por branches, no próximo post vamos ver como trabalhar com imagens.

Categorias
AMP Accelerated mobile pages JavaScript Tutoriais

Introdução ao AMP

AMP ou Accelerated mobile pages surgiu para solucionar um problema antigo das aplicações web relacionado a performance, o fato que muitas das aplicações web são desenvolvidas nos grandes centro onde as empresas e usuários tem facilmente acesso a conexão rápida. Quando as aplicações são testadas nos grandes centros não levam em conta o tempo de carregamento da aplicação em uma conexão lenta, e um dos dos objetivos do AMP foi solucionar este problema e e entregar essa informação priorizando performance.

Sabemos conexões rápidas não se aplica ao resto do planeta muitas regiões ao redor do globo continuam tendo dificuldade de acessar conteúdo online. Como podemos promover a inclusão desses grupos preocupado com esse problema o time do Google criou o projeto open source chamado Accelerated Mobile Pages posteriormente chamado apenas de AMP.

Mas esse problema também afeta os grandes centros usuários mobile com conectividade limitada também tem sua experiência prejudicada, todos esses problemas aumentam o tempo de carregamento e na exibição de elementos na tela. Além do fato que aplicações de alta performance ajudam na taxa de conversão usuários, que tais usuários estão cada vez mais utilizando aplicações web através de dispositivos moveis.

AMP permite a criação de sua aplicação em um curto espaço de tempo, isso através de componentes criando um ambiente de fácil manutenção além promover melhores praticas como:

  • Performance
  • Acessibilidade
  • Confiabilidade
  • Design responsivo

Além disso AMP reduz a complexidade do seu código, mas sem perder o controle de sua aplicação você continua com a capacidade de adicionar código CSS para customizar sua aplicação. O set de componentes já existentes ajudam na agilidade na criação de novas aplicações presando a performance. AMP é um projeto open source a comunidade sem está criando novos componentes e novas versões da aplicação e a base do seu código sempre será atualizada

Como AMP funciona

AMP possui três pilares:

  • AMP HTML extende HTML básico criando novas tags criando novas features, por trás das cortinas ele trabalha com web components
  • AMP JS controla a execução de javascript também adicionando melhorias de performance como tree shaking.
  • AMP Cache armazena o conteúdo da aplicação.

A performance dentro de projetos AMP é possível por conta de alguns pontos chaves que iremos listar a seguir.

JavaScript assíncrono

com javascript podemos modificar todos os aspectos de uma página, mas também bloquear o seu processamento caso não especificarmos que o seu carregamento não afete a renderização da página. Nesse caso todo o carregamento de JavaScript em AMP é feito de forma assíncrona para não afetar a entrega do conteúdo.

Por isso AMP restringe o carregamento de JavaScript escrita pelo autor nesse caso temos que utilizar tags especiais para incluir interação com o usuário.

Evita que extensões de terceiros bloqueiem a renderização

AMP não permite que extensões como, lightboxes, instagram, embers, tweets bloqueiem a renderização do seu conteúdo. Muitos desses items enquanto fazem requisições para suas respectivas APIs bloqueiam a renderização da sua aplicação, mas isso não significa que que você não poderá utilizar esses recursos AMP tem uma série de componentes para interagir com outras plataformas.

Tamanho de todos os recursos estaticamente

Recursos como imagens, iframes ou anúncios, precisam informar seu tamanho no HTML, de modo que AMP possa determinar o tamanho e a posição de cada elemento antes que os recursos sejam baixados. AMP carrega o layout da página sem esperar o download de nenhum recurso.

AMP separa o layout HTML dos recursos externos, isso para priorizar a entregar com conteúdo mais rápido possível. Apenas uma solicitação HTTP é necessária para o todo o layout do documento (+ fontes). Como AMP é otimizado para evitar recálculos de estilo no seu navegador, não haverá nenhum novo layout após a ultima requisição.

Gerenciamento de Javascript de terceiros

AMP mantém todos os scripts de terceiros fora do caminho crítico da renderização das páginas. JS de terceiros gostam de usar carregamento síncrono para executar suas tarefas para garantir sua execução mas isso acaba aumentando o tempo de carregamento da aplicação.

Páginas AMP permitem o carregamento de scripts de terceiros mas apenas em iframes. Com isso o carregamento fica isolado e não afeta o processamento principal de nossas páginas. Mesmo que eles afetem o estilo da página o impacto será mínimo.

Atualizando o post enquanto estava escrevendo este post

CSS inline e com tamanho limitado

O CSS externo como sabemos bloqueia a renderização de nossa página, nas páginas AMP somente estilos inline são permitidos, com isso temos uma requisição a menos em nossa aplicação e uma renderização crítica de nossa aplicação web.

Além disso a folha de estilo in-line é limitada para um máximo de 50kb. Embora esse tamanho seja grande o suficiente para páginas muito sofisticadas, ele ainda exige que o autor mantenha o CSS limpo.

Carregamento eficiente de fontes

As fontes web são uma parte visual importante das nossas aplicações web, portanto, a otimização de fontes é um ponto crucial de nossa aplicação algumas web fonts são bem pesadas aumentando o tamanho total da nossa aplicação. AMP realiza optimização no carregamento de fontes e realiza o preload nossas fontes.

Animações somente utilizando a GPU

O único modo de ter uma aplicação de alta performance é realizado o uso eficiente dos recursos e utilização da GPU é um recurso importante para isso. Todas as animações com AMP são executadas pela GPU assim liberando a thread principal para processamento crítico de nossa aplicação.

Priorização do carregamento dos recursos

AMP controla o carregamento de todos recursos: com isso os recursos serão carregados quando realmente necessários utilizando técnicas como lazy-load e prefetch.

Além disso AMP possui uma lista de prioridade exemplo, imagens estão no topo da lista enquanto ads estão no final dessa lista. Outro fator importante para priorização é quais os recursos estão sendo exibidos para o usuário.

Utilização de novas API para reduzir o tempo de carregamento

A nova API preconnet API é usada intensamente para garantir as solicitações HTTP sejam feitas o mais rápido possível. Com isso a página pode ser pre carregada em background, por isso algumas vezes quando clicamos nos primeiros resultados de uma busca no Google temos o carregamento instantâneo.

Embora o pré-processamento possa ser aplicado a todo o conteúdo da web, ele também ajuda na largura de banda e o uso de CPU.

Web Components

Com AMP HTML temos a possibilidade de utilizar uma variedade de componentes web, utilizando somente elementos nativos da plataforma o framework disponibiliza uma série de componentes reutilizáveis para entregarmos uma aplicação interativa.

Esse são alguns dos items relevantes na plataforma a lista completa você pode encontrar na documentação em amp.dev. Em meu canal do youtube estarei rodando um curso sobre o framework onde você pode conferir a playlist do curso aqui: https://www.youtube.com/playlist?list=PLmIA3VZysEqQxsVcZ7u2ZHOnh78eIOKON

Também confira mais posts na página da categoria AMP.

Categorias
JavaScript Tutoriais

Badging API

A Badging API é uma das novas APIs criadas para fechar o gap entre aplicações nativas, a badging API foi incluída na versão 73 do Chrome em versão de teste, permite adicionar contador de notificações nos ícones de nossa PWA na barra de tarefas, diferente de push notification badging api é menos intrusiva apenas exibe um balão de notificação sobre o ícone de nossa aplicação, atualmente Window 7+ e MacOS possuem suporte a essa funcionalidade através de token especial para o recurso.

Google iniciou um projeto com foco na inclusão de novas funcionalidades e o mais legal que esse projeto será baseado em requisições feitas pela comunidade para saber mais sobre o projeto acesse o link:
https://developers.google.com/web/updates/capabilities

Casos sugeridos para utilizar a badging API

  • Aplicações de Chat, email e social apps que precisam notificar que o usuário recebeu novas mensagens
  • Aplicações precisa sinalizar que processos que estavam rodando em background foram concluídas
  • Jogos que estão aguardando uma ação do usuário.

Requisitos

  • Chrome 73 ou superior
  • Aplicação precisa estar instalada como PWA

Como utilizar

A partir da versão 73 a Badging API está disponível através de um recurso chamado Origin trials(Versões de avaliação) ele permite testar novas features e dar feedback de usabilidade, praticidade e eficiência. Caso queira saber mais sobre o projeto acesse o link.

Registrando para Versões de avaliações

  1. Requiste um token para sua origin
  2. Adicione o token em sua página, temos dois modos para prover esse recurso em qualquer página de sua versão de teste.
    1. Adicionando uma meta tag origin-trial no cabeçalho de sua aplicação
    2. Se você tiver acesso a configuração do seu servidor, você também pode prover um token em sua página adicionando a propriedade Origin-Trial em seu HTTP header.
    3. Se você quiser testar localmente também pode fazer o uso habilitando a flag #enable-experimental-web-platform-features acessando o endereço chrome://flags
Caso queira utilizar o token você pode essa será a página de requisição

Para esse tutorial vamos utilizar a flag do chrome, atualmente(maio 2019) estamos na versão 74 a previsão do uso definitivo desse recursos será na versão 78. Caso esteja lendo este post com a versão do Chrome 78 ou superior esse passo não será necessário. Mas para quem utiliza versão inferior a 78 vamos habilitar o recurso acessando o endereço chrome://flags:

Para facilitar nossa vida podemos pesquisar por “experimental web” para ir diretamente a flag. Após nossa flag habilitada precisamos reiniciar nosso Chrome para o recurso funcionar em nosso browser.

Agora que habilitamos a flag hora de testar o recurso, a badging API tem duas funções window.ExperimentalBadge.set() para definir o contador e window.ExperimentalBadge.clear() para limpar nosso contador.

Para os nossos testes vamos utilizar como base o projeto que estou desenvolvendo no mini curso de PWA que estou rodando no Youtube.

Inicialmente vamos adicionar dois botões em nossa página:

<button class="badingAPI__add">Add</button>
<button class="badingAPI__clean">Clean</button>

Nosso JavaScript ficará da seguinte forma:

const addBadge = document.querySelector('.badingAPI__add');
const cleanBadge = document.querySelector('.badingAPI__clean');
let counterBadge = 0;
let bagdeTimer;

if (addBadge) {
  addBadge.addEventListener('click', () => {
    if (counterBadge === 0) {
      bagdeTimer = window.setInterval(() => {
        counterBadge += 1;
        window.ExperimentalBadge.set(counterBadge);
        console.log('counter');
      }, 1000);
    }
    console.log('triggered');
  });

  if (cleanBadge) {
    cleanBadge.addEventListener('click', () => {
      counterBadge = 0;
      window.ExperimentalBadge.clear();
      clearInterval(bagdeTimer);
    });
  }
}

No Código acima realizamos uma simulação da atualização das notificações com um setInterval(), quando o usuário clica no botão “add” inicializamos o contador, passamos como parâmetro um número dentro da função set, caso queiramos apenas exibir o balão sem um número, chamamos a função set sem passar nenhum parâmetro. Numa aplicação real atualizamos o contador quando temos uma mensagem não lida ou precisamos completar alguma tarefa.

No macOS podemos ver o contador de notificações funcionando

Para o botão clean, quando o usuário clicar no botão, zeramos o contador e removemos a execução do nosso timer com clearInterval, e para remover a badge do ícone chamamos a função: window.ExperimentalBadge.clear().

Esse recurso está em modo de teste mas em breve será incorporado sem o uso de flag no Chrome para acompanhar o status e conferir mais informações acesse: https://developers.google.com/web/updates/2018/12/badging-api

Esse material faz parte do curso de PWA que estou rodando em meu canal do Youtube, para acompanhar as aulas sigam meu canal ou acessem a página do curso: https://blog.fellyph.com.br/curso-online-progressive-web-apps/

Qualquer dúvida só deixar um comentário e até o próximo post!

Categorias
PWA - Progressive web apps

Media queries para Progressive Web Apps

Se você me segue no Twitter já viu que estou criando uma série sobre Progressive Web Apps, neste mini curso estou abordando os principais recursos na construção de um PWA. Para esse post vamos falar sobre um conteúdo complementar como adicionar um estilo específico através media queries para identificar uma PWA.

Se você ainda não ouviu falar sobre Progressive web apps ou aplicações web progressivas, PWA não é uma biblioteca ou framework, mas uma filosofia. Uma definição rápida seria o desenvolvimento de uma aplicação com uso de técnicas e recursos para proporcionar progressivamente uma melhor experiência para o usuário com foco em três pontos:

  • Confiabilidade
  • Velocidade
  • Engajamento

Quer saber mais acesse acompanhe a playlist do mini curso:

Também me siga no youtube para acompanhar mais vídeos

Voltando ao tema principal, quando construímos nossa PWA utilizamos o manifest.json, arquivo responsável por configurar nossa PWA, nome da aplicação(name e short_name), URL de inicialização(start_url), ícones(icons) e modo de exibição(display). O modo de exibição é o ponto chave deste tutorial e ele possui os seguintes modos:

  • fullscreen – como o nome sugere exibe em modo full screen sem nenhum elemento de interface do browser
  • standalone – Exibe como uma aplicação independente do browser, mas dependendo do sistema operacional podendo exibir alguns elementos de controle de navegação, por exemplo, iOS não exibe itens de navegação mas permite o controle de navegação através de gestos.
  • minimal-ui – Esse modo é exibido como uma aplicação independente mas forca a exibição de elementos de navegação
  • browser – Esse modo exibe como um browser convencional

Fullscreen e standalone

Agora que a gente teve uma introdução sobre os modos disponíveis, dois modos precisam de atenção especial fullscreen e standalone eles precisam prover uma navegação dentro da aplicação pois os elementos de navegação do browser são removidos, com isso o usuário pode ficar preso em sua aplicação e isso não é uma boa experiência.

Para isso podemos implementar media query para controlar a exibição controle de navegação ou apenas estilizar nossa aplicação. Atualmente temos um seletor para display-mode dentro de media queries, com isso podemos implementar media queries para diferentes modos, mas lembrando que a media query precisa seguir o parâmetro definido em seu manifest.json.

Media query para desktop e mobile

//media query para o modo de exibicao standalone presente tanto em mobile e desktop 
@media (display-mode: standalone) {
 
}

No código acima temos uma media query para o formato standalone, suportado por PWAs que rodam no desktop ou mobile, mas poderíamos utilizar um dos quatros padrões que vimos anteriores.

Um fato relevante neste momento até a versão 12.2 do iOS não temos suporte ao web app manifest em outras palavras iOS não utiliza o manifest.json, a definição de ícones e títulos para nossa PWA é feito através de meta tags dentro de nosso HTML, e elas apenas suportam o formato standalone.

Caso utilize um formato diferente de standalone precisamos ter duas media queries uma para android e outra para iOS

//media query para MacOS e iiOS
@media (display-mode: standalone) {
 
}

//media query para Android caso definido no manifest.json
@media (display-mode: fullscreen) {
 
}

Media query para iOS

Mas o código acima pode perder sua funcionalidade quando iOS começar a suportar web app manifest, mas caso queiramos ter uma estilização estritamente para iOS, por simples motivo cada sistema operacional tem seu guia de interface, por exemplo, Android geralmente exibe seus items de navegação na base da tela enquanto iOS exibe os elementos de navegação no topo da aplicação.

Com media query podemos incluir mais uma regra dentro de nosso media query o “@supports” com ele podemos realizar filtros através de features suportada pelo browser, por exemplo, suporte a display grid podemos utilizar o seguinte código:

@supports (display: grid) {
  div {
    display: grid;
  }
}

Agora que sabemos desse recurso como podemos implementar essa regra com PWA? Temos algumas features apenas suportada pelo iOS no caso temos “-webkit-overflow-scrolling” presente apenas no safari mobile. Com isso podemos da seguinte forma:

/* 
 - podemos utilizar display mode em: standalone, fullscreen, minimal-ui e browser
*/

@media (display-mode: standalone) {
  /*To das as pwas instaladas desktop e mobile */
}

@media (max-width: 576px) and (display-mode: standalone) {
  /* Filtro para pwas instalada apenas em dispositivos moveis */
  
  @supports (-webkit-overflow-scrolling: touch) {
    /* PWAs instaladas apenas no iOS */
  }
  
  @supports not (-webkit-overflow-scrolling: touch) {
    /* PWAs instaladas em dispositivos não iOS */
  }
}

Com o código acima cobrimos os principais casos para PWA, em breve estarei postando um vídeo sobre esse assunto para seguir o conteúdo dessa série confira os post sobre Progressive web apps. Caso tenha alguma dúvida só deixar um comentário.

Categorias
JavaScript Tutoriais

Introdução a Webpack

Webpack é um static module bundler ou numa tradução genérica um “empacotador de módulos”, mas o que isso significa? Webpack vai gerenciar a leitura de arquivos de seu projeto empacotando esse conteúdo da forma que você desejar. Ele irá funcionar de forma recursiva, um arquivo funciona como ponto de partida, a partir desse ponto inicial ele irá varrer todos os arquivos que estão conectados em sua aplicação e para cada caso teremos um tratamento específico.

Qual a vantagem disso tudo? Ainda é comum aplicações web carregando dezenas JavaScript com diferentes script tags, se você não fizer isso da maneira correta irá causa uma série de problemas de performance em sua aplicação. E o gerenciamento de módulos ataca alguns problemas de performance, por padrão Webpack trabalha apenas com o carregamento de Javascript, mas podemos instalar recursos necessários para trabalhar com CSS, imagens, arquivos SASS, LESS e TypeScript. Esses “recursos” são chamados de loaders que veremos em breve.

Atualmente na versão 4 Webpack esté entre as principais ferramentas de configuração de ambiente, anteriormente ocupadas pelo Gulp e o Grunt. O que impulsionou sua popularidade foi a adoção por grandes CLI’s do mercado, com angular-cli e create-react-app conseguimos abstrair toda a complexidade de realizar a configuração inicial de projetos com Angular ou React e Webpack é um grande responsável por toda essa mágica por trás dos CLIs.

Vale salientar que funcionamento do Webpack é um pouco diferente do Gulp e Grunt, eles são gerenciadores de tarefas enquanto o Webpack é um gerenciador de módulos, o seu foco é como os arquivos serão carregados separados por extensão, mas claro que podemos trabalhar uma série de recursos que o gulp/grunt realizam, por exemplo, toda parte de optimização, minificação, tratamento de arquivos e concatenação.

O processo de leitura com Webpack é dividido em 4 conceitos chaves:

  • Entry: qual será o nosso arquivo de entrada, o nosso ponto inicial
  • Output: nosso arquivo final gerado
  • Loaders: para cada tipo de arquivo o Webpack possui um loader devemos gerenciar este ponto no nosso arquivo de configuração
  • Plugins: Webpack disponibiliza uma série de plugins, para diferentes tipos de situações

Nas versões anteriores nos iniciávamos um projeto com o arquivo webpack.config.js nele especificamos como o Webpack ira se comportar. Na versão nova do Webpack podemos iniciar um projeto sem o arquivo de configuração, mas voce quiser realizar optimizações extra com o o webpack.config.js

Preparativos

Para esse tutorial vamos criar um projeto simples com dois arquivos, a estrutura será a seguinte, cada passo desse tutorial irei criar uma branch para voce acompanha a evolução dos arquivos, por exemplo, step-1… step-2… step-3… O nosso ponto de partida será o seguinte:

Temos um aquivo index.html e dentro da pasta SRC temos uma index.js

Antes de iniciar a instalação do Webpack, voce irá precisar de uma versão atualizada do nodeJS/NPM, podemos verificar a versão do nosso NPM com o comando em nosso terminal:

npm -v

Na raiz no nosso projeto vamos inicializar o nosso pacote NPM(step-2), nele vamos salvar todas as dependências para o nosso projeto, assim em nosso terminal executamos o comando:

npm init

Na imagem acima temos o final do passo-a-passo realizar pelo NPM init, ele ira verificar se ja temos um arquivo package.json, caso não, ele irar nos ajudar a criar um, fazendo perguntas sobre os campos necessários e ao final ele gerar uma arquivo package.json:

{
  "name": "webpack-tutorial",
  "version": "1.0.0",
  "description": "Tutorial about webpack",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" &amp;&amp; exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/fellyph/webpack-tutorial.git"
  },
  "keywords": [
    "tutorial",
    "webpack"
  ],
  "author": "fellyph",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/fellyph/webpack-tutorial/issues"
  },
  "homepage": "https://github.com/fellyph/webpack-tutorial#readme"
}

Com o nosso package.json configurado agora vamos instalar o webpack e webpack-cli em nosso projeto(step-3), voltando para o terminal vamos executar os seguintes comandos:

npm install webpack webpack-cli --save-dev

Se tudo correr bem teremos a confirmação em nosso terminal:

Caso a versão do seu node não suporte a última versão do Webpack, voce receberá um alerta para atualizar o seu nodeJS and NPM. Agora vamos criar a determinada situação para fazer uma comparação após usarmos Webpack. Inicialmente vamos adicionar três novos scripts(content.js, header.js e footer.js) ao nosso projeto e carrega-los em nossa index.html(isso voce poderá acompanhar na branch step 4).

Simulando uma conexão lenta o resultado será o seguinte. Temos 4 requisições durando um total de 4.29 segundos.

Uma ação de melhorar a performance de um site é reduzir o numero de requisições, em browsers modernos e conexões HTTP2 isso não tao visível. Mas quando não temos esse recursos temos uma limitação de requisições em paralelo isso causa um efeito cascata aumentando o tempo de carregamento. Uma solução para isso será enviar um único bundle contendo todos os arquivos, agora vamos verificar como fazer isso com webpack primeiro vamos definir o nosso webpack.config.js:

const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'main.js'
  }
};

No arquivo acima tempos temos instruções qual é o arquivo de entrada neste caso o index.js e qual arquivo será gerado dentro da pasta ‘dist’ o arquivo main.js. E nosso index.js importa os três arquivos, content.js, header.js e footer.js

var myContent = require('./js/content');
var myHeader = require('./js/header');
var myFooter = require('./js/footer');

O Webpack irá ler o arquivo index.js e varrer todos os arquivos relacionados e criar um arquivo único simulando uma conexão lenta o resultado será o seguinte:

Agora temos duas requisições 2 requisições em 4.24 segundos

Até o momento não fizemos nenhuma otimização esse post serviu como uma introdução, nos próximos posts podemos evoluir o nosso projeto e aumentar sua complexidade. O código final você encontra aqui: https://github.com/fellyph/webpack-tutorial/tree/step-5