Praticantes de SEO sempre desconfiaram do JavaScript.
Isto é parcialmente baseado na experiência; A capacidade dos mecanismos de pesquisa de descobrir, rastrear e indexar com precisão conteúdo que depende muito do JavaScript tem sido historicamente deficiente. Mas também é comum, nascido de uma cautela geral em relação ao JavaScript em todas as suas formas, que não seja baseada em compreensão ou experiência. Isso se manifesta como uma dependência de técnicas tradicionais de SEO que não são relevantes há anos, e a convicção de que, para ser bom em SEO técnico, não é necessária uma compreensão do desenvolvimento moderno da web.
Como Mike King escreveu em sua publicação The Technical SEO Renaissance, essas atitudes estão contribuindo para "uma crescente lacuna de conhecimento técnico dentro de SEO como um campo de marketing, o que torna difícil para muitos SEO resolver nossos novos problemas". Eles também colocam os profissionais de SEO em risco de serem deixados para trás, pois muitos de nós se recusam a explorar, muito menos a adotar tecnologias como Progressive Web Apps (PWA), frameworks JavaScript modernos e outros avanços semelhantes que são cada vez mais considere mais o futuro da web.
Neste artigo, vou dar uma olhada nos PWAs. Além de explorar as implicações para SEO e usabilidade, mostrarei alguns frameworks modernos e ferramentas de construção que você pode não ter ouvido falar, e vou sugerir maneiras de nos adaptarmos se nos colocarmos na vanguarda da tecnologia. da web.
1. Resumo: PWAs, SPAs e trabalhadores de serviços
Aplicações web progressivas são essencialmente sites que fornecem Uma experiência do usuário semelhante à de um aplicativo nativo.. Recursos como notificações automáticas permitem um novo compromisso com seu público-alvo, enquanto os usuários podem adicionar seus sites favoritos à tela inicial sem o incômodo das lojas de aplicativos. Os PWAs podem continuar a operar off-line ou em redes de baixa qualidade e permitem uma experiência de tela inteira de nível mais alto em dispositivos móveis, mais próxima da oferecida pelos aplicativos iOS e Android nativos.
O melhor de tudo, os PWAs fazem isso enquanto retêm e até melhoram os Natureza aberta e acessível da web.. Como o nome sugere, eles são progressivo e sensato, projetado para funcionar com todos os usuários, independentemente da sua escolha de navegador ou dispositivo. Eles também podem ser atualizados automaticamente e, como veremos, eles são descoberto e conectável como sites tradicionais. Por fim, não é tudo ou nada: os sites existentes podem implementar um subconjunto limitado dessas tecnologias (usando um trabalhador de serviço simples) e começar a obter os benefícios imediatamente.
A especificação ainda é bastante jovem e, é claro, há áreas que precisam funcionar, mas isso não impede que elas sejam um dos maiores avanços em recursos da Web em uma década. A adoção do PWA está crescendo rapidamente e as organizações estão descobrindo a miríade de metas de negócios reais que podem impactar.
Você pode ler mais sobre os recursos e requisitos do PWA no Google Developers, mas duas das principais tecnologias que tornam o PWA possível são:
- Aplicativo de arquitetura da shell: Comumente alcançado usando uma estrutura JavaScript, como React ou Angular, isso se refere a uma maneira de criar aplicativos de página única (SPA) que separa a lógica do conteúdo real. Pense no aplicativo shell como o mínimo de HTML, CSS e JS que seu aplicativo precisa para funcionar; um esqueleto de sua interface de usuário que pode ser armazenado em cache.
- Trabalhadores do serviço: Um script especial que o seu navegador executa em segundo plano, separado da sua página. Basicamente age como um proxy, interceptando e gerenciando solicitações de rede de sua página programaticamente.
Tenha em mente que essas tecnologias não são mutuamente exclusivas; O modelo de aplicativo de uma página (posto em amadurecimento com o AngularJS em 2010) obviamente precede o serviço e os funcionários do PWA por algum tempo. Como veremos, também é completamente possível criar um PWA que não seja construído como um aplicativo de uma página. Para os fins deste artigo, no entanto, vamos nos concentrar na abordagem "típica" para o desenvolvimento de sistemas modernos de APO, Explorando as implicações do SEO – e oportunidades – enfrentados por equipes que optam por se juntar ao crescente número de organizações que fazem uso do duas tecnologias descritas acima.
Começaremos com a arquitetura de shell do aplicativo e as implicações de representação do modelo de aplicativo de página única.
2. O aplicativo de arquitetura.
URLs
Em suma, a arquitetura de shell do aplicativo envolve o armazenamento em cache agressivo de ativos estáticos (o mínimo de interface do usuário e funcionalidade) e, em seguida, o carregamento do conteúdo real dinamicamente, usando JavaScript. Os mais modernos frameworks de SPA do JavaScript encorajam algo como essa abordagem, e a separação da lógica e do conteúdo dessa maneira beneficia ambos. velocidade e usabilidade. As interações parecem instantâneas, como as de um aplicativo nativo, e o uso de dados pode ser muito econômico.
Crédito para https://developers.google.com/web/fundamentals/architecture/app-shell
Como mencionei na introdução, uma grande dependência de JavaScript no lado do cliente é um problema para SEO. Historicamente, muitos desses problemas se concentravam no fato de que, embora os rastreadores de pesquisa precisem de URLs exclusivos para descobrir e indexar conteúdo, os aplicativos de página única não é necessário alterar o URL para cada estado do aplicativo ou site (daí a frase "página única"). A confiança nos identificadores de fragmentos, que não são enviados como parte de uma solicitação HTTP, para manipular dinamicamente o conteúdo sem recarregar a página era um grande problema para o SEO. As soluções legadas consistiam em substituir o hash pelo chamado hashbang (#!) E pelo parâmetro _escaped_fragment_, um hack que há muito tempo foi desaprovado e que não será explorado hoje.
Graças a API de história em HTML5 e o método pushState, agora temos uma solução melhor. A barra de URL do navegador pode ser alterada usando JavaScript sem recarregar a página, portanto, ela permanece sincronizada com o status do seu aplicativo ou site e permite que o usuário faça uso efetivo do botão "voltar" do navegador. Embora esta solução não seja uma solução mágica (seu servidor deve ser configurado para responder às solicitações dessas URLs profundas ao carregar o aplicativo em seu estado inicial correto), ela nos fornece as ferramentas para resolver o problema de URL no SPA.
// Execute isso no seu console para modificar o URL no seu // browser: observe que a página não é recarregada. history.pushState (null, "Page 2", "/page2.html");
O maior problema enfrentado hoje pelo SEO é muito mais fácil de entender: renderizar conteúdoa saber quando e Como? se faz
Conteúdo de renderização
Tenha em mente que quando me refiro à representação aqui, eu me refiro ao processo de construindo o HTML. Estamos nos concentrando em como a corrente conteúdo ele alcança o navegador, não o processo de desenhar pixels na tela.
Nos primeiros dias da web, as coisas eram mais simples nessa frente. O servidor normalmente retornaria todo o HTML necessário para representar uma página. Hoje em dia, no entanto, muitos sites que usam uma estrutura de aplicativo de página única fornecem apenas o mínimo de HTML do servidor e delegam trabalho pesado ao cliente (um usuário ou um bot). Dada a escala da web, isso requer muito de tempo e recursos computacionais, e como o Google deixou claro em sua conferência de E / S em 2018, isso representa um grande problema para os mecanismos de pesquisa:
"A representação de websites baseados em JavaScript na Pesquisa do Google é adiada até que o Googlebot tenha recursos disponíveis para processar esse conteúdo."
Em sites maiores, essa segunda onda de indexação pode às vezes ser adiada vários dias. Além disso, é provável que você encontre muitos problemas com informações cruciais, como tags canônicas e metadados, que estão completamente perdidos. Recomendaria que você assistisse ao vídeo da excelente conversa do Google sobre esse tópico para aprender sobre alguns dos desafios enfrentados pelos rastreadores de pesquisa modernos.
O Google é um dos poucos mecanismos de pesquisa que processam JavaScript. Além disso, ele faz isso usando um serviço de representação na Web que, até recentemente, era baseado no Chrome 41 (lançado em 2015). Obviamente, isso tem implicações fora dos aplicativos de uma página e O tópico mais amplo do JavaScript SEO é uma área fascinante. agora mesmo. O último artigo de Rachel Costello sobre JavaScript SEO é o melhor recurso que eu li sobre o assunto, e inclui contribuições de outros especialistas, como Bartosz Góralewicz, Alexis Sanders, Addy Osmani e muitos mais.
Para os propósitos deste artigo, o ponto chave aqui é que, em 2019, você não pode confiar nos mecanismos de pesquisa para rastrear e renderizar com precisão seu aplicativo da Web que depende do JavaScript. Se o seu conteúdo estiver do lado do cliente, o Google usará muitos recursos para rastreá-lo e seu site terá menos desempenho na pesquisa. Não importa o que você ouviu, pelo contrário, Se a busca orgânica for um canal valioso para o seu site, você deve providenciar a representação do lado do servidor.
Mas a representação do lado do servidor é um conceito que muitas vezes é mal interpretado …
"Implementar a representação do lado do servidor"
Esta é uma recomendação comum de auditoria de SEO que eu ouço frequentemente como se fosse uma solução autônoma e fácil de ação. No melhor dos casos, é uma simplificação excessiva de uma grande empresa técnica e, no pior dos casos, é uma má interpretação do que é possível / necessário / benéfico para o site em questão. A representação do lado do servidor é um Saída de muitas configurações possíveis e pode ser alcançado de muitas maneiras diferentes; Em última análise, no entanto, estamos preocupados fazendo nosso servidor retornar HTML estático.
Então, quais são nossas opções? Vamos dar uma olhada no conceito de conteúdo renderizado no lado do servidor e explorar nossas opções. Estas são as abordagens de alto nível que o Google descreveu na conferência de E / S mencionada acima:
- Representação dinâmica – Aqui, os navegadores normais obtêm o aplicativo da Web "padrão" que exige representação do lado do cliente, enquanto os robôs (como o Googlebot e os serviços de rede social) são exibidos com instantâneos estáticos. Isso envolve a adição de uma etapa adicional à infraestrutura do seu servidor, ou seja, um serviço que recupera seu aplicativo da Web, processa o conteúdo e retorna esse HTML estático aos robôs com base em seu agente do usuário (ou seja, o rastreamento) da UA). Historicamente, isso foi feito com um serviço como o PhantomJS (agora fora de uso e não foi desenvolvido), enquanto hoje Puppeteer (Chrome sem cabeça) pode executar uma função similar. A principal vantagem é que você pode freqüentemente se conectar à sua infraestrutura existente.
- Representação híbrida Essa é a recomendação de longo prazo do Google, e é absolutamente o caminho a seguir para novas compilações de sites. Em suma, todos, bots e humanos, obtêm a visão inicial como um HTML estático totalmente renderizado. Os rastreadores podem continuar solicitando URLs dessa maneira e obter conteúdo estático todas as vezes, enquanto nos navegadores normais, o JavaScript assume o controle após o carregamento da página inicial. Esta é uma ótima solução Em teoriae vem com muitas outras vantagens em termos de velocidade e facilidade de uso; mais sobre isso em breve.
O último é mais limpo, não envolve o rastreamento do UA e é uma recomendação de longo prazo do Google. Também vale a pena esclarecer que "representação híbrida" não é uma solução única, é o resultado de muitas abordagens possíveis para disponibilizar conteúdo estático no servidor. Vamos decompor como esse resultado pode ser alcançado.
Aplicações isomórficas / universais.
Essa é uma maneira de obter uma configuração de "representação híbrida". Aplicativos isomórficos usam JavaScript, que é executado no servidor e no cliente. Isso é possível graças à chegada do Node.js, que, entre muitas outras coisas, permite que os desenvolvedores escrevam códigos que podem ser executados no servidor e no navegador.
Em geral, você configurará sua estrutura (React, Universal Angular, whatever) para executar em um servidor Node, apresentando parte ou todo o HTML antes de enviá-lo ao cliente. Portanto, seu servidor deve ser configurado para responder a URLs profundos processando HTML para a página correspondente. Em navegadores normais, esse é o ponto no qual o aplicativo do lado do cliente assumirá sem problemas. O HTML estático processado pelo servidor para a exibição inicial é "reidratado" (termo brilhante) pelo navegador, converte-o de volta em um aplicativo de página única e executa eventos de navegação subseqüentes com JavaScript.
Se bem feita, essa configuração pode ser fantástica, pois oferece os benefícios de usabilidade da representação do lado do cliente, os benefícios de SEO da renderização do lado do servidor e uma primeira pintura rápida (mesmo que o tempo de interação seja frequentemente é negativamente afetado pela reidratação quando JS chuta). em). Por receio de simplificar demais a tarefa, não vou entrar em muitos outros detalhes aqui, mas o ponto-chave é que, embora a renderização isomórfica do servidor JavaScript / true possa ser uma solução poderosa, Muitas vezes, é extremamente complexo configurar.
Então, quais outras opções existem? Se você não pode justificar o tempo ou o custo de uma configuração isomórfica completa, ou se é simplesmente um exagero para o que você está tentando alcançar, existe alguma outra maneira de fazer isso? Obtenha os benefícios do modelo de aplicativo de página única e a configuração de representação híbrida, sem sabotar seu SEO?
Pré-renderização / JAMstack
Ter conteúdo disponível disponível do lado do servidor não significa necessariamente que o processo de representação em si Tem que acontecer no servidor. Tudo o que precisamos é que o HTML renderizado esteja lá, pronto para servir o cliente; O processo de renderização em si pode acontecer onde você quiser. Com um Abordagem JAMstack, a representação de seu conteúdo em HTML acontece como parte de seu processo de compilação.
Eu escrevi sobre a abordagem JAMstack antes. Como introdução rápida, o termo significa JavaScript, APIs, e margeme descreve uma maneira de criar sites complexos sem software do lado do servidor. O processo de montar um site a partir de componentes front-end, uma tarefa que um site tradicional poderia alcançar com o WordPress e PHP, é executado como parte do processo de compilação, enquanto a interatividade é tratada no lado do cliente usando JavaScript e API.
Pense desta maneira: tudo Viva no seu repositório Git. Seu conteúdo é armazenado como arquivos de redução de texto simples (editáveis por meio de um CMS sem cabeçalho ou outra solução baseada em API) e os modelos de página e lógica de montagem são escritos em Go, JavaScript, Ruby ou em qualquer idioma. para usar o gerador de sites preferencial. Seu site pode ser integrado em HTML estático em qualquer computador com o conjunto certo de ferramentas de linha de comando antes de Está hospedado em qualquer lugar. O conjunto resultante de arquivos estáticos que são armazenados facilmente no cache geralmente pode ser armazenado com segurança em um CDN por quase nada.
Honestamente, acredito que os geradores de sites estáticos, ou melhor, os princípios e tecnologias que os sustentam, são o futuro. Há muitas chances de que eu esteja errado sobre isso, mas o poder e a flexibilidade da abordagem devem ser claros para qualquer um que tenha usado software de automação moderno baseado em npm, como Gulp ou Webpack, para criar seu CSS ou JavaScript. Eu desafiaria qualquer um a testar a integração profunda do Git oferecida pelo especialista em rede Netlify em um projeto do mundo real e ainda acredito que a abordagem do JAMstack é uma moda passageira.
O significado de uma configuração de JAMstack para nossa discussão de aplicativos de página única e a apresentação anterior deve ser bastante óbvio. Se nosso gerador de site estático puder montar HTML baseado em modelos escritos em Liquid ou Handlebars, por que você não pode fazer o mesmo com JavaScript?
Existe uma nova geração de geradores estáticos de sites que fazem exatamente isso. Frequentemente orientados por React ou Vue.js, esses programas permitem que os desenvolvedores criem sites usando estruturas JavaScript de última geração e possam ser facilmente configurados para gerar HTML estático e compatível com SEO para cada página (ou "caminho"). Cada um desses arquivos HTML é conteúdo completamente renderizado, pronto para ser consumido por humanos e robôs, e serve como ponto de entrada para uma aplicação completa no lado do cliente (ou seja, um aplicativo de uma página). Essa é uma execução perfeita do que o Google chama de "representação híbrida", embora a natureza precisa do processo de representação anterior a distingue de uma configuração isomórfica.
Um ótimo exemplo é o GatsbyJS, que é construído em React e GraphQL. Não vou entrar em muitos detalhes, mas gostaria de encorajar todos aqueles que lerem aqui a consultar sua homepage e a excelente documentação. É uma ferramenta bem suportada com uma curva de aprendizado razoável, uma comunidade ativa (uma versão v2.0 completa foi lançada em setembro), uma arquitetura extensível baseada em complementos, integrações enriquecidas com muitos CMS e permite que os desenvolvedores usem estruturas modernas Como reagir sem sabotar seu SEO. Há também o Gridsome, baseado no VueJS, e o React Static, que, como você deve ter adivinhado, usa o React.
Adoção no nível do negócio A partir dessas plataformas, parece que vai crescer; O GatsbyJS foi usado pela Nike para a sua campanha Just Do It, Airbnb pelo seu site de engenharia airbnb.io, e a Braun até o usou para dirigir um importante site de comércio eletrônico. Finalmente, nossos amigos SEOmonitor usaram para impulsionar seu novo site.
Mas isso é o suficiente com os aplicativos de uma única página e a representação do JavaScript por enquanto. É hora de explorarmos a segunda das nossas duas principais tecnologias que sustentam o PWA. Promessa Você vai ficar comigo até o fim (haha, piada nerd), porque é hora de explorar os trabalhadores do serviço.
3. trabalhadores de serviço
Em primeiro lugar, devo esclarecer que as duas tecnologias que estamos explorando, o SPA e os trabalhadores de serviços, são Não é mutuamente exclusivo. Juntos, eles suportam o que comumente chamamos de aplicativo da Web progressivo, sim, mas também é possível ter um PWA que não seja um SPA. Você também pode integrar um service worker em um site tradicional estático (ou seja, sem qualquer conteúdo de renderização no lado do cliente), que é algo que acho que veremos muito mais acontecendo no futuro próximo. Finalmente, os trabalhadores de serviços operam em conjunto com outras tecnologias, como o Manifest Web App, algo que minha colega Maria recentemente explorou com mais detalhes em seu excelente guia PWA e SEO.
Em última análise, no entanto, São os funcionários do serviço que tornam possíveis as funções mais interessantes do PWA.. Eles são uma das mudanças mais significativas para a plataforma da web em sua história e para todos aqueles cujo trabalho é construir, manter ou auditar um site. necessariamente Estar ciente desse novo e poderoso conjunto de tecnologias. Se, como eu, você está analisando entusiasticamente a página Jake Archibald está pronto para trabalhar nos últimos dois anos e já viu como a adoção pelos fornecedores de navegadores cresceu, você saberá que agora é a hora de começar a construir com os trabalhadores do serviço.
Vamos explorar o que eles são, o que podem fazer, como implementá-los e quais são as implicações para o SEO.
O que os trabalhadores de serviços podem fazer?
Um trabalhador de serviço é um tipo especial de arquivo JavaScript que é executado fora do segmento principal do navegador. Está localizado entre o navegador e a rede e seus poderes incluem:
- Interceptando solicitações de rede e decidir o que fazer com eles programaticamente. O trabalhador pode ir para a rede normalmente ou pode depender unicamente do cache. Eu poderia até faça uma resposta completamente nova de uma variedade de fontes. Isso inclui a construção de HTML.
- Pré-carregamento do arquivo durante a instalação do trabalhador de serviço. Para SPAs, isso geralmente inclui o "shell de aplicativo" que discutimos anteriormente, enquanto sites estáticos simples podem escolher pré-carregue todo o HTML, CSS e JavaScript, garantindo que a funcionalidade básica permaneça offline.
- Manipulando notificações por push, semelhante a um aplicativo nativo. Isso significa que os sites podem obter permissão dos usuários para enviar notificações e, em seguida, confiar no funcionário do serviço para receber mensagens e executá-las mesmo quando o navegador está fechado.
- Executando sincronização de plano de fundo, adiando as operações de rede até que a conectividade tenha melhorado. Isso pode ser uma "caixa de saída" para um serviço de webmail ou um serviço de upload de fotos. Não há mais "solicitação com falha, tente novamente mais tarde": o funcionário do serviço cuidará de você no momento certo.
Os benefícios desse tipo de recursos vão além das vantagens óbvias da usabilidade. Tanto como impulsionando a adoção de HTTPS através da web (todos os principais navegadores só registram os trabalhadores do serviço no protocolo seguro), os trabalhadores de serviços são transformadores quando se trata de velocidade e desempenho. Ele suporta novas abordagens e ideias, como o Padrão PRPL do Google, já que podemos maximizar a eficiência do armazenamento em cache e minimizar a dependência da rede. Dessa forma, os funcionários de serviços desempenharão um papel fundamental para tornar a web rápida e acessível para o próximo bilhão de usuários da web.
Então sim, eles são um poder absoluto.
Implementando um trabalhador de serviço
Aqui, em vez de fazer um trabalho ruim ao escrever um tutorial básico, vou me conectar a alguns recursos importantes. Afinal, você está na melhor posição para saber o quão profunda deve ser sua compreensão sobre os trabalhadores de serviços.
O MDN Docs é um bom lugar para aprender mais sobre os trabalhadores de serviços e suas capacidades. Se você já está seguro com os elementos essenciais do desenvolvimento web e desfrute de um aprender fazendo abordagem, recomendo que você conclua o curso de treinamento do Google PWA. Inclui um exercício prático sobre trabalhadores de serviços, o que é uma excelente maneira de se familiarizar com o básico. Se o ES6 e as promessas não fizerem parte do seu repertório de JavaScript, prepare-se para um batismo de fogo.
A chave para o entendimento, e que você vai perceber muito rapidamente depois de começar a experimentar, é que os trabalhadores de serviço entregam um incrível nível de controle para os desenvolvedores. Ao contrário das tentativas anteriores de resolver o enigma da conectividade (como o AppCache mal-sucedido), os trabalhadores de serviço não aplicam nenhum padrão específico ao seu trabalho; Eles são um conjunto de ferramentas para você escrever suas próprias soluções para os problemas que enfrenta.
Uma conseqüência disso é que elas podem ser muito complexas. Registrar e instalar um trabalhador de serviço não é um exercício simples, e qualquer tentativa de improvisar colando e copiando o StackExchange está fadada ao fracasso (sério, não faça isso). Não existe um funcionário de serviço pronto para o seu site. – Se você deseja criar um funcionário adequado, deve entender a infraestrutura, a arquitetura e os padrões de uso do seu site. O tio Ben, sempre o guru do desenvolvimento web, disse melhor: Com grande poder vem uma grande responsabilidade.
Uma última coisa: você provavelmente ficará surpreso com quantos sites que você visita já estão usando um trabalhador do serviço. Vá para chrome: // serviceworker-internals / no Chrome ou sobre: debugging # workers no Firefox para ver uma lista.
Trabalhadores de serviços e SEO
Em termos de implicações de SEO, a coisa mais importante para os trabalhadores de serviços é provavelmente sua capacidade de seqüestrar solicitações e modificar ou fabricar respostas usando a API de busca. O que você vê em "Visualizar código-fonte" e até mesmo na guia Rede Não é necessariamente uma representação do que foi retornado do servidor.. Pode ser uma resposta em cache ou algo criado pelo funcionário do serviço a partir de várias fontes diferentes.
Crédito: https://developer.mozilla.org/pt-BR/docs/Web/API/Fetch_API
Aqui está um exemplo prático:
- Ir para a página inicial do GatsbyJS
- Clique no link para a página "Documentos".
- Clique com o botão direito – Ver a fonte
Sem conteúdoCerto? Apenas alguns scripts e estilos on-line e elementos HTML vazios: um aplicativo JavaScript clássico do lado do cliente integrado ao React. Mesmo se você abrir a guia Rede e atualizar a página, as guias Visualizar e Responder contarão a mesma história. O conteúdo real aparece apenas no inspetor de elemento, porque o DOM está sendo montado com JavaScript.
Agora, execute uma solicitação de curvatura para a mesma URL (https://www.gatsbyjs.org/docs/) ou pesquise a página usando o Screaming Frog. Todo o conteúdo está lá., juntamente com as tags de título, tags canônicas e tudo mais que você pode esperar de uma página do lado do servidor. Isso é o que um rastreador, como o Googlebot, também verá.
Isso ocorre porque o site usa a representação híbrida e um service worker, instalado em seu navegador, está lidando com os eventos de navegação subseqüentes. Você não precisa obter o HTML bruto para a página Documentos do servidor porque o aplicativo do lado do cliente já está em execução e, portanto, Visualizar código-fonte mostra o que trabalhador de serviço retornou ao aplicativoNão é o que a rede retornou. Além disso, essas páginas podem ser recarregadas enquanto desconectadas, graças ao uso efetivo do cache pelo service worker.
Você pode detectar facilmente quais respostas vieram do service worker usando a guia Rede: veja a linha 'do Service Worker' abaixo.
Na guia Aplicativo, você pode ver o service worker que está sendo executado na página atual junto com os diferentes caches que você criou. Você pode desativar ou omitir o trabalhador e tentar qualquer uma das funções mais avançadas que você pode estar usando. Aprender a usar essas ferramentas é um exercício extremamente valioso; Eu não entrarei em detalhes aqui, mas eu recomendaria estudar o tutorial de Conceitos Básicos na web do Google sobre depuração de trabalhadores de serviços.
Eu fiz um esforço consciente para manter os fragmentos de código ao mínimo neste artigo, mas me dê este. Eu coloquei um exemplo que ilustra como um trabalhador de serviço simples pode usar a API de busca para lidar com as solicitações e o grau de controle que elas fornecem:
O resultado:
Espero que este exemplo (enormemente simplificado e não pronto para produção) ilustre um ponto chave, ou seja, que temos Controle extremamente granular sobre como as solicitações de recursos são tratadas. No exemplo anterior, optamos por um simples tente-cache-primeiro, volte para a rede, volte para a página personalizada Padrão, mas as possibilidades são infinitas. Os desenvolvedores estão livres para ditar como as solicitações devem ser tratadas com base em nomes de host, diretórios, tipos de arquivos, métodos de solicitação, atualização de cache e muito mais. As respostas, incluindo as páginas completas, podem ser fabricadas pelo trabalhador do serviço. Jake Archibald explora alguns métodos e abordagens comuns em seu livro de receitas offline.
O tempo para aprender sobre as capacidades dos trabalhadores de serviços é agora. O conjunto de habilidades necessárias para SEO técnico moderno tem um certo grau de sobreposição com o de um desenvolvedor web, e hoje, um Entendimento profundo de ferramentas de desenvolvimento em todos os principais navegadores – Incluindo a depuração do trabalhador de serviço – deve ser considerado como um pré-requisito.
4. envolvimento
SEO precisa se adaptar
Hasta hace poco, ha sido muy fácil no entender las consecuencias y oportunidades que presentan los PWA y los trabajadores de servicios.
Estas fueron características de vanguardia que se encontraban en la periferia de lo que era relevante para el marketing de búsqueda, y la cautela mencionada de muchos SEO para JavaScript no hizo nada para fomentar la experimentación. Pero los PWA están rápidamente en camino de convertirse en una norma, y pronto será imposible hacer un trabajo efectivo sin entender la mecánica de Como? funcionan Para seguir siendo relevante como SEO técnico (o Ingeniero de SEO, para tomar otro término de Mike King), debe ponerse a la vanguardia de este tipo de desarrollos que cambian de paradigma. El SEO técnico que es analfabeto en desarrollo web ya es un anacronismo., y creo que una mayor divergencia entre los aspectos técnicos y de contenido impulsado por el marketing de búsqueda no es algo malo. ¡Especializarse!
Al enterarse de que un equipo de desarrollo está adoptando un nuevo marco de JavaScript para la creación de un nuevo sitio, no es raro que los SEO reaccionen con un grado de cinismo. Ciertamente, soy culpable de bromear sobre los desarrolladores que se sienten atraídos por la última tecnología o marco brillante, y por la rapidez con la que el mundo del desarrollo de JavaScript parece evolucionar, capa por capa de abstracción y automatización añadidas a lo que, desde el exterior, a menudo puede Parece ser una torre inclinada de una pila de desarrollo. Pero vale la pena tomarse el tiempo para entender por qué se eligen los marcos, quando Es probable que las tecnologías comiencen a utilizarse en la producción, y Como? Estas decisiones impactarán en el SEO.
En lugar de criticar el manejo 404 o el enlace interno de un marco de aplicación de una sola página, por ejemplo, sería mucho mejor poder ofrecer recomendaciones significativas que se basen en una comprensión de cómo funcionan realmente. Como observó Jono Alderson en su charla sobre la democratización del SEO, las contribuciones a los proyectos de código abierto son más valiosas para difundir la apreciación y el conocimiento del SEO que corregir repetidamente los mismos problemas sobre una base ad hoc.
Más allá de SEO
Una última cosa que me gustaría mencionar: los PWA son un conjunto de tecnologías tan transformador que obviamente tienen consecuencias que van mucho más allá del SEO. Otras áreas del marketing digital también se ven afectadas directamente, y desde mi punto de vista, una de las más interesantes es analítica.
Si su sitio web es parcial o totalmente funcional sin conexión, ¿ha adaptado su configuración de análisis para tener esto en cuenta? Si las suscripciones de notificaciones automáticas son un KPI para su sitio web, ¿está usted siguiendo esto como un objetivo? Recordando que los trabajadores del servicio no tienen acceso al objeto Window, no es posible rastrear estos eventos con el código de seguimiento "normal". En su lugar, es necesario configura tu trabajador de servicio para construir éxitos utilizando el Protocolo de medición, póngalos en cola si es necesario y envíelos directamente a los servidores de Google Analytics.
Esta es un área fascinante que he estado explorando mucho últimamente, y puedes leer la primera publicación de mi serie de artículos sobre análisis de PWA en el blog Builtvisible.
¡Eso es todo de mi parte por ahora! Gracias por leer. Si tiene alguna pregunta o comentario, deje un mensaje a continuación o escríbame en Twitter @tomcbennet.
Muchas gracias a Oliver Mason e Will Nye por sus comentarios sobre un primer borrador de este artículo.
