em um post de blog hoje, o Google está anunciando que está formalmente embarcando em um projeto para convencer o grupo encarregado dos padrões da web a adotar tecnologia inspirada em seu framework de páginas móveis aceleradas (AMP). Em teoria, significaria que virtualmente qualquer página web poderia ganhar os mesmos benefícios que AMP: carregamento quase instantâneo, distribuição em múltiplas plataformas, e (criticamente) colocação mais proeminente nas propriedades do Google.

isto soa impenetravelmente denso e aborrecido, mas por favor não Clique ainda!, Isto é importante, um pouco complicado de entender, e crítico para como a web e o Google interagem no futuro. Em muitos aspectos, o sucesso ou fracasso do Google neste empreendimento irá desempenhar um papel importante na configuração de como a web funciona no seu telefone.

Se você não está familiarizado, AMP é a tentativa do Google de fazer páginas web tão rápido e portátil como outros “artigos instantâneos” (como o que você pode ler no Facebook ou Apple News). A idéia é que quando você clicar em um link nessas outras plataformas, você não tem que esperar pelo artigo para carregar porque ele já está pré-carregado em um aplicativo., O objetivo da AMP é trazer o mesmo desempenho para a própria web.

ao criar AMP, O Google blithely caminhou diretamente para o centro de um espesset composto por desenvolvedores preocupados com o futuro da web. Os editores estão preocupados em ceder o controle de sua distribuição a empresas tecnológicas gigantescas, e todos OS acima estão preocupados que o Google não seja tanto um mordomo da web, mas sim seu nefasto puppet master.,

Todos os que a angústia tem metástase nos últimos meses, com uma amplamente divulgada carta aberta para o Google, pedindo para correção de amplificadores, mais de Meio de postagens de blog que pode ser lido em uma semana, o Twitter mesa, e os argumentos nos comentários de AMP do próprio GitHub repositório de código. E isso é apenas o material vindo de desenvolvedores da web. (Eu tenho uma pasta de favoritos que eu chamo de “AMPhole” para tentar acompanhar, e esse buraco fica mais profundo quase todos os dias.)

toda a situação é ligeiramente frustrante para David Berbris, VP de engenharia de pesquisa no Google., No início desta semana, fui a Mountain View falar com Besbris e Malte Ubl, engenheiro líder da AMP. “Este é honestamente um projeto altruísta da nossa perspectiva”, diz Besbris.”não foi como se tivéssemos inventado o AMP porque queríamos controlar tudo, como as pessoas assumem”, diz ele. Em vez disso, ele argumenta, voltar e olhar para o quão terrível o estado da web móvel era há alguns anos, antes da criação da AMP. Foi uma porcaria — na verdade, Nilay Patel publicou uma história neste mesmo site intitulado “the mobile web sucks” em 2015. Ele tinha razão., A Apple e o Facebook lidaram com esse problema criando formatos proprietários e, em seguida, convenceram os editores a distribuir suas notícias nesses formatos em suas plataformas. Como Nilay escreveu:

Tomados em conjunto, Notícias da Apple e Facebook Instant Artigos são mais tristes refutação da web aberta revolução possíveis: eles são incompatíveis proprietários de sistemas de publicação inteiramente sob o controle de grandes corporações, nem de que particularmente compreende a publicação ou a mídia.,

Besbris via as coisas da mesma forma: “a tendência na indústria na época era a maneira simples de resolver esses problemas, onde você garantia que você poderia controlar a experiência … mas isso vem ao custo da web.”Então a solução do Google foi AMP, um framework que foi projetado para tornar a web tão boa quanto essas plataformas para que a web realmente tivesse uma chance de competir com a Apple e o Facebook.fazer páginas web instantâneas e portáteis requereu um hack muito inteligente — e muito kludgey.,

The hack involved a combination of existing web technologies( like iFrames), stricted standards on webpages themselves (so they would be guaranteed to load fast), and — criticamente — a different kind of infrastructure for how webpages get from a publisher’s server to your phone. Estes kludges são muitas vezes as coisas que você vê as pessoas se queixam quando eles se queixam de AMP. as iFrames têm um comportamento estranho de deslocamento, URLs não coincidem, e os resultados AMP muitas vezes parecem anêmicos quando comparados com páginas web completas. (Fixes for all of those issues either exist or have been proposed.,)

apesar de todos esses problemas, aqui está o que é impressionante sobre AMP: quando você publica uma página web, ela pode ser servida a partir de qualquer servidor de cache. Mas isso não é o que realmente o torna rápido; o que realmente faz a diferença é que ele pode carregar quase instantaneamente porque ele já foi pré-carregado em segundo plano. E no entanto, apesar desse pré-carregamento, você não conta como visitante e o editor não pode definir quaisquer cookies ou fazer qualquer rastreamento até que você clique., E você pode confiar que a página cache, carregada instantaneamente que está no Google search ou Twitter é fiel à sua fonte canônica, mesmo que essa fonte tenha sido atualizada após a sua primeira publicação.

“de volta no início, foi bastante assumido que a web não poderia fazer nada disso”, diz Bsbris. A Ubl e sua equipe inventaram essa combinação de tecnologias que tornou possível, mas requereu tecnologia que não está realmente incorporada na web agora., Então o Google enfrentou uma escolha: tomar o tempo para tentar convencer o órgão de padrões da web a adotá-lo e fabricantes de navegador para apoiá-lo ou simplesmente ir em frente e colocá-lo no mundo como um projeto apoiado principalmente pelo Google nos próprios produtos do Google, principalmente pesquisa.precisamos de um veículo para descobrir. Não se pode saber sem experimentar coisas”, argumenta Bsbris. O Google tinha que provar que a web poderia ser tão boa quanto Artigos Instantâneos. Mais importante, ele teve que ficar tão bom rapidamente — antes que as pessoas o abandonaram para um milhão de aplicativos personalizados e formatos de artigos diferentes., Besbris diz que o Google não podia esperar pelos Comitês que ajudam a criar padrões web para fazê-lo. “Se você começar por tentar tudo através do processo de padrões, nós ainda estaríamos falando sobre isso”, argumenta ele.

Se o AMP conta ou não como “a web” é na verdade um dos pontos de discórdia — embora como seria de esperar, Besbris e Ubl acreditam fortemente que é, e eles fazem um argumento convincente para isso. As páginas móveis aceleradas, segundo eles, não precisam usar os servidores do Google ou servir anúncios do Google; eles podem ser publicados e distribuídos de forma completamente independente do Google.,

independentemente do que os engenheiros do Google pensam, fora de Mountain View, AMP está associado muito mais fortemente com o Google do que com a web — embora tenha sido adotado por Bing, Twitter, Baidu e outros. Parte do problema é que AMP foi a reação do Google ao Facebook e Apple, então ele caiu no balde de pensamento Fácil de “formatos de artigos proprietários.”Mas a maior parte é que o Google é enorme e tem empurrado AMP de uma forma grande com o seu maior Produto: pesquisa. Os editores que apoiam a AMP aparecem no carrossel do Google top stories, O que significa uma inundação de tráfego., É um grande incentivo para apoiar AMP.

E assim, finalmente, estamos prontos para falar sobre o post de hoje do Ubl. Você precisa de toda essa história para entender o seguinte, uma frase aparentemente simples que explica o que o Google está fazendo:

com base no que aprendemos com AMP, agora nos sentimos prontos para dar o próximo passo e trabalhar para suportar conteúdo de carregamento mais rápido não baseado na tecnologia AMP em áreas da Pesquisa do Google projetadas para isso, como o carrossel Top Stories.,

o Que o Google está propondo não é para ligar a web inteira no AMP, mas, ao invés de tomar algumas das ideias por trás inteligente hacks que fez AMP trabalho, limpá-los e, em seguida, torná-los um padrão universal, que não tem nada a ver com o Google. Dessa forma, quase qualquer webpage poderia ser distribuído tão facilmente e carregado tão rapidamente quanto aqueles que são suportados por AMP.

Google is not blind: it knows that other companies are not likely to up and adopt AMP as a universal solution to fixing the web., Embora o Ubl possa alegremente descobrir quantos não Googlers contribuem para o código AMP, no final do dia, ele trabalha no Google e é o Bdfl (ditador benevolente para a vida) no projeto AMP. Os novos padrões — muitos dos quais já estão em desenvolvimento — parecem ser realmente bons para a web. Mas também é importante, eles são genuinamente mais propensos a serem adotados por empresas concorrentes se eles são vistos como novas tecnologias fundamentais da web e não apenas um projeto Google.,

“nossa intenção sempre foi tomar AMP-obter as partes boas e as lições que aprendemos com a construção AMP — na faixa de padrões”, diz Besbris.

Este novo formato ainda não tem um nome — o Google é obviamente reticente em propor um — mas seja o que for, é provável que abarque uma gama de tecnologias propostas., Ubl tenho profundo nas ervas daninhas de algumas dessas comigo, mas vou poupar-vos, e em vez de apontar para os links em seu blog:

o objetivo do Google é oferecer apoio em recursos como as principais notícias do carrossel para AMP-como conteúdo que: (1) atende a um conjunto de desempenho e experiência do usuário, critérios e (2) implementa um conjunto de novos padrões web. Alguns dos padrões propostos no caminho crítico são a Política de recursos, embalagem Web, promoção iframe, Cronologia de desempenho e cronometragem de pintura.,

os próximos passos vão provavelmente envolver um processo que, no meu mais otimista, eu diria que levará meses — mais provável que serão anos. Vários organismos de normalização têm de apresentar propostas, experimentá-las e concordar com elas. E não é apenas o corpo W3C que padroniza a web, também. A tecnologia de embalagem Web que permite que as páginas web funcionem offline e sejam redistribuídas pode realmente precisar de ser acordada por outro organismo.

E depois de tudo isso, as empresas que fazem navegadores web e aplicativos precisam implementar tudo isso., Quando eu ousei Ubl para adivinhar o que a linha do tempo para tudo isso pode ser, ele descreveu o que ele esperava que o processo poderia parecer por um bom tempo antes de admitir, “a esse respeito, não, nenhuma linha do tempo.”

Entretanto, o Google vai absolutamente continuar a desenvolver AMP e promover o seu uso. Mas para acelerar ao longo do processo padrão, ele está oferecendo a mesma cenoura que originalmente sobrecarregou o crescimento de AMP: colocação primária nas próprias propriedades do Google. O Google promete que qualquer página web que corresponda ao desempenho de uma página AMP receberá exatamente o mesmo tratamento na pesquisa do Google.,

o Google não é capaz de fornecer um “punchlist” de recursos que ele vai exigir, antes de uma página podem receber o mesmo tratamento como AMP — pelo menos não ainda. Demorou tanto tempo para a equipe por trás do AMP para descobrir que a tecnologia por trás dele poderia ser universalizado (ou, se preferir, de-Googlized), então ele vai trabalhar com o resto da comunidade da web para realmente fazê-lo antes de tomar quaisquer decisões firmes sobre o que está acontecendo para obter tratamento especial em pesquisar., O Google tem algumas ideias-incluindo benchmarks de desempenho para páginas e suporte para pacotes web de carregamento instantâneo-mas ainda não se compromete com uma lista firme.

Uma vez que estes padrões são acordados e implementados, qualquer página que esteja em conformidade com eles pode aparecer no Top Stories carousel, o Google news feed no Android, e até mesmo obter o mesmo pequeno distintivo blue lightning bolt que aparece ao lado dos resultados suportados por AMP em busca. Estas páginas não serão garantidas melhor colocação em resultados de pesquisa, no entanto — assim como AMP não garante colocação de pesquisa hoje., “As coisas que você precisa fazer para se classificar bem em busca continuará lá e nós continuaremos a não lhe dizer o que eles são”, piadas de Besbris.

Eu não acho que o post do Ubl hoje vai lavar os sentimentos ruins que muitos têm sobre AMP. Há muita coisa embrulhada nela. AMP tem servido como uma embarcação para preocupações sobre o poder do Google sobre a web, o futuro arriscado de publicação de notícias, e qualquer que seja a angústia geral que todos nós sentimos sobre o estado lamentável da maioria das páginas web móveis., A maioria dessas preocupações tem sido justa, mas não houve impulso suficiente para uma alternativa mais aberta. Com este movimento, o Google parece estar tentando criar um.

Aqui está como Besbris resume as notícias de hoje:

a intenção aqui é ser melhor em comunicar a nossa intenção. Sempre quisemos e sempre dissemos isto, mas não muito claramente. … Nós só queremos comunicar muito claramente que AMP não é nada mais do que tentar tornar a web melhor., As lições aprendidas com a AMP estão a ser colocadas nos organismos padrão, para que possamos ter outros quadros a implementar o mesmo material também.

a discussão sobre AMP desde o seu início tem sido confusa e controversa. Normalmente é assim com os padrões da web. Mas eu acho que os riscos com AMP se sentem mais altos do que as batalhas anteriores por causa de uma crescente compreensão de que não podemos tomar mais a existência da Web aberta como garantida. Pode muito bem desaparecer. Tem de ser mantida e, mais do que isso, melhorada.,isso não quer dizer que todos devem confiar totalmente no Google para ter os melhores interesses da Web aberta no coração. A empresa certamente beneficia mais do que seus concorrentes de uma web forte e vibrante e é tão influente na web que às vezes parece Dominação. O Google poderia ser um pouco mais consciente dessas realidades quando fala sobre a web.à medida que começamos a terminar a nossa discussão sobre AMP, Besbris repete uma das minhas perguntas: “temos sido idiotas ao comunicar estas coisas?”

” Sim, ” ele responde.,