Como não aprender design de urls: os Hashbangs

Um dos grandes problemas de requisições AJAX é o fato de as engines de busca, como o Google, não possuírem uma forma simples e direta de realizar o crawling das páginas para que seus conteúdos apareçam nos resultados de buscas. Com isso, é muito comum que sites que foram desenvolvidos inteiramente utilizando AJAX, tenham apenas a Home visível nos resultados do buscador.

Para tentar resolver este problema, o Google propôs uma maneira para indicar que as interações feitas através de requisições AJAX pudessem ser indexadas. Essa proposta sugeria que os desenvolvedores ao criarem seus links que disparariam requisições assíncronas, alterassem sua URL através da adição de fragmentos, que indicam algum id de elemento ou uma âncora existente na página, seguida de uma exclamação, como em http://www.acme.com/um_livro#!capitulo2.

Ao utilizarmos em conjunto os caracteres #! nas URLs, temos o que ficou conhecido como hashbang.

Alguns sites utilizam essa técnica, como o Twitter: http://twitter.com/#!/caelum. Ao clicar em algum link que gere requisição AJAX nessa página, a URL mudará para outra contendo esse mesmo padrão, como em: http://twitter.com/#!/caelum/followers. Com isso, agora o Googlebot ao navegar por essas páginas, conhece quais são essas URLs e pode indexá-las.

Um outro exemplo de site que tem se utilizado da mesma técnica é o http://lifehacker.com.

Desvantagens práticas

Uma primeira desvantagem nessa abordagem, é que a partir de agora o site possui apenas 1 endereço válido, que é o caso do twitter com a http://www.twitter.com. Dessa forma, quando acessamos http://www.twitter.com/#!/caelum, o que é acessado é a Home do twitter, que possui um código Javascript cuja função é disparar uma requisição AJAX para exibir os dados adequados a partir das informações contidas após o hashbang. Isso faz com que um acesso à esses dados se torne consideravelmente mais lento.

Além disso, se houver o menor erro nesse Javascript, a página inteira pode deixar de ser carregada. E isso de fato aconteceu: no dia do lançamento do novo Lifehacker, um pequeno problema com JavaScript tornou o site inteiro inacessível durante horas.

Um outro ponto que deve ser levado em consideração é que ao utilizar hashbangs nas URLs, cria-se um acoplamento forte entre a URL e o Javascript que tem como função dar “significado” ao conteúdo da URL. Com isso, se futuramente for decidido utilizar alguma alternativa ao hashbang, o ideal é manter todas as URLs antigas funcionando, ou seja, nessa situação o Javascript será sempre necessário.

Outra desvantagem é a quebra da acessibilidade das páginas, um exemplo é tentar  visualizar o código fonte dos seguidores de alguma pessoa no twitter. O código fonte devolvido não é o que está sendo visualizado. Isso pode limitar a acessibilidade das páginas, pois alguns dispositivos ou softwares podem não interpretar esses Javascripts.

Qual é a alternativa ao hashbang?

Atualmente, com o HTML5, é possível fazer com que páginas que utilizam requisições AJAX para exibir conteúdos sejam facilmente indexadas pelos mecanismos de busca. Isso se dá através da History API que permite que com uma simples chamada de JavaScript, troquemos a URL do nosso navegador.

A partir de métodos como o history.pushState e history.replaceState controlamos a URL que está sendo acessada no site e assim podemos exibir novos conteúdos carregados via AJAX.

Um exemplo de uso é o Github, onde ao navegarmos pelo código de algum projeto, como por exemplo o VRaptor, a navegação na estrutura de diretórios do projeto é uma requisição AJAX disparada para buscar o novo conteúdo. Ainda assim, a URL é alterada normalmente sem hashbang, como https://github.com/caelum/vraptor/tree/master/vraptor-core. Repare que não é preciso mais onerar as URLs com carecteres estranhos.

Cuidar das suas URLs desde o momento da sua criação e mantê-las funcionais é primordial para qualquer site. O bom design de uma URL pode fazer com que seu site aumente consideravelmente o número de requisições recebidas, mas para isso não é preciso fazer endereços específicos para mecanismos de busca, nesse caso, bastaria usar a History API. Vários tópicos de Web avançados como HTML5 são vistos no curso WD-43.

16 Comentários

  1. Arthur Carvalho 14/04/2011 at 11:12 #

    Ótimo post!
    Desconhecia sobre o assunto de hashbangs. Ainda bem!

  2. Max Mustang 14/04/2011 at 12:55 #

    Post perfeito Adriano, parabens 😀

  3. Hugo Roque (a.k.a hugolnx) 14/04/2011 at 13:02 #

    Bem legal o post 😀
    n ão sabia que o nome disso era hashbang.
    eu implementei meu blog(http://hugolnx.com/) desta maneira que você mostrou, por enquanto ainda está simples, por isso ainda nao tive muitos problemas, nem me preocupei ainda de usar o “!” para o crawler do google.

    Achei bem interessante a alternativa que você deu de usar HTML5, porém ainda não resolve o problema do acoplamento que você citou certo?

    Uma alternativa que eu havia pensado para amenizar isso( e estava planejando implementar no meu blog conforme ele ficasse mais complexo) seria fazer com que a requisição ajax fosse feita pelo javascript simplesmente chamando a url depois da hash para o servidor, e este renderizaria a pagina inteira caso nao fosse uma requisição ajax, ou somente o conteudo caso fosse.

    Na teoria isso diminuiria o acoplamento. No caso deste tipo de requisição, acoplar com javascript me parece inevitavel.

    Curti bastante o post, em breve eu devo implementar esta alternativa ao hashbang usando HTML5.

  4. Adriano Almeida 14/04/2011 at 13:23 #

    Oi Hugo, tudo bem?

    O acoplamento existente no hashbang é entre a URL e o Javascript. Como a URL possui o #, ela não tem significado nenhum e é o JS quem dá o significado pra ela.

    A alternativa da History API, você não tem hashbangs, logo, todas as suas URLs tem significado, com isso é possível sempre que eu quiser, acessar diretamente o conteúdo (sem precisar de um JS intermediário), que é justamente o caso do Github, por exemplo.

    Sobre a sua sugestão, isso é uma as coisas que fazem parte da sugestão que o Google deu para os hashbangs, onde você ainda teria os hashbangs, mas também disponibilizaria seu conteúdo em uma outra URL sem hashbangs. A relação entre sua URL com o #! e o Javascript vai continuar existindo da mesma forma e é justamente isso que tem que ser evitado.

    []’s

  5. Hugo Roque (a.k.a hugolnx) 14/04/2011 at 15:55 #

    Olá,
    Agora entendi, o acoplamento se dá pelo fato do browser ignorar o que está depois de “#” e termos de tratar isso via AJAX até quando o usuário acessa diretamente a aplicação pela URL com hashbang.

    Novamente, ótimo post, flwz aew

  6. Tiago Albineli Motta 14/04/2011 at 23:55 #

    As paginações to TechTudo também já estão todas no estilão html5 com pushState. Muito mais limpo e prático.

  7. Sérgio Lopes 16/04/2011 at 03:58 #

    Parece que a reformulação de design do Gawker / Lifehacker / Gizmodo derrubou pela metade as visitas nesses sites:

    http://techcrunch.com/2011/02/17/gawker-redesign/

    Muita gente não gostou do layout novo. Mas há quem diga que isso está diretamente ligado a performance ruim do novo Site, com load time de ate 3x pior que antes:

    http://www.webperformancetoday.com/2011/02/28/gawker-slow-web-site-performance/

    Essa perda de performance está diretamente ligada à questão do Hashbang. Como a implementação do Site depende de JavaScript, eles são carregados no topo, executados e só depois o conteúdo é mostrado. Numa página HTML normal, com progressive render, o conteúdo já começaria a ser mostrado assim que o HTML fosse baixado.

    Mais um motivo pra não usar hashbangs.

  8. sombriks 18/04/2011 at 21:39 #

    Post interessante, mas só mostra uma parte do problema. Esses ‘hashbangs’ são um de vários tokens possíveis para desmontar a url, sem falar nos casos onde não há tokens.

    Dado o luxo dos id’s presentes na url de não modificarem a localização atual, qualquer combinação que envolva id’s de elemento, existentes ou não mas que sirvam para manobras de javascript, irá acarretar esse problema de design.

    Só uma ressalva, até certo ponto pessoal, não concebo mais a web sem javascript, então não acho falha de design depender de javascript primordialmente. Mesmo em sites acessíveis.

    Acho muito válido evitar esse tipo de subsistema na grande internet, afinal há outras formas bem decentes de se fazer isso.

  9. Adriano Almeida 18/04/2011 at 23:07 #

    Oi sombriks,

    perfeito comentário. O hashbang foi só o que ganhou mais notoriedade, muito provavelmente por ter tido a google por trás.

    Sobre o Javascript, concordo com você, também não consigo enxergar uma Web atualmente sem Javascript. A falha de design não é em depender de Javascript, mas sim depender de Javascript por conta das suas URLs, isso é falha de design.

    Abraço

  10. VitorGGA 06/05/2011 at 11:44 #

    Achei legal o jeito q o LifeHacker usa com o HTML5, e vi tbm que em outros navegadores véios nao funciona e o navegador chama mesmo a nova página, aparecendo tudo normal. Bom!

  11. Ruan Mér 06/05/2011 at 12:00 #

    otimo post

  12. Pedro Reys 06/05/2011 at 12:57 #

    No caso do Gawker, eles, quando lançaram o novo site, chegaram a “quebrar” o botão “Back” dos browsers com o uso de hashbangs.

    http://lostechies.com/jimmybogard/2011/04/05/gawker-sites-breaking-the-web/

  13. Julio Bitencourt 23/09/2011 at 17:12 #

    O google não indica o uso de _escaped_fragment_ para indexar conteúdos em Ajax?

    É recomendavel?

    http://www.seomoz.org/blog/how-to-allow-google-to-crawl-ajax-content

  14. Filipe Costa 13/12/2011 at 14:02 #

    show a dica.
    parabéns!

  15. Adriano Almeida 14/10/2015 at 16:31 #

    E hoje, 14/10/2015, o Google anunciou que está deprecando os #!: http://googlewebmastercentral.blogspot.com.br/2015/10/deprecating-our-ajax-crawling-scheme.html

Deixe uma resposta