Quel est le tralala / Hashbang (#!) Dans Facebook et Twitter pour les nouvelles URL?

Question

Je viens de remarquer que les longues URL alambiquées Facebook que nous sommes habitués à ressembler à ceci:

http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345

Pour autant que je me souvienne, plus tôt cette année, il était juste une chaîne normale fragment comme URL (en commençant par #), sans point d'exclamation. Mais maintenant il est un tralala ou Hashbang (#!), que je l'ai déjà vu que dans les scripts shell et des scripts Perl.

Le nouveau Twitter URLs de maintenant comportent également les symboles #!. Une URL de profil Twitter, par exemple, ressemble maintenant à ceci:

http://twitter.com/#!/BoltClock

Est-ce que #! joue maintenant un rôle particulier dans les URL, comme pour un certain cadre Ajax ou quelque chose depuis les nouvelles interfaces Facebook et Twitter sont maintenant en grande partie Ajaxified? Est-ce que l'utilisation dans mes URL profiter de mon application Web de quelque façon?

Answer 1

Cette technique est maintenant dépréciée .

utilisé pour indiquer à Google comment indexer la page.

https://developers.google.com/webmasters/ajax-crawling/

Cette technique a surtout été supplanté par la possibilité d'utiliser l'API JavaScript History qui a été présenté aux côtés de HTML5. Pour une URL comme www.example.com/ajax.html#!key=value, Google vérifiera l'URL www.example.com/ajax.html?_escaped_fragment_=key=value chercher une version non-AJAX du contenu.

Answer 2

Le dièse / numéro signe / hachure a une signification particulière dans une URL, il identifie normalement le nom d'une section d'un document. Le terme précis est que le texte suivant le hachage est la partie ancre d'une URL. Si vous utilisez Wikipedia, vous verrez que la plupart des pages ont une table des matières et vous pouvez passer directement à des sections dans le document avec une ancre, par exemple:

https://en.wikipedia.org/wiki/Alan_Turing#Early_computers_and_the_Turing_test

https://en.wikipedia.org/wiki/Alan_Turing identifie la page et Early_computers_and_the_Turing_test est l'ancre. La raison pour laquelle Facebook et d'autres applications pilotées par Javascript (comme mon Bois et pierres ) utilisent des ancres est qu'ils veulent faire des pages bookmarkable (comme l'a suggéré un commentaire sur cette réponse) ou d'appuyer sur le bouton retour sans recharger la page entière du serveur .

Afin de soutenir bookmarking et le bouton de retour, vous devez changer l'URL. Cependant, si vous changez la partie de la page (avec quelque chose comme window.location = 'http://raganwald.com';) à une autre URL ou sans spécifier un point d'ancrage, le navigateur va charger la page entière de l'URL. Essayez ceci dans la console Javascript Firebug ou Safari. http://minimal-github.gilesb.com/raganwald de charge. Maintenant, dans la console Javascript, tapez:

window.location = 'http://minimal-github.gilesb.com/raganwald';

Vous verrez l'actualisation de la page du serveur. Maintenant, tapez:

window.location = 'http://minimal-github.gilesb.com/raganwald#try_this';

Aha! Pas de rafraîchir la page! Type:

window.location = 'http://minimal-github.gilesb.com/raganwald#and_this';

Toujours pas de rafraîchissement. Utilisez le bouton arrière pour voir que ces URL sont dans l'historique du navigateur. Le navigateur constate que nous sommes sur la même page mais juste changer l'ancre, il ne se recharge pas. Merci à ce comportement, nous pouvons avoir une seule application Javascript qui apparaît dans le navigateur pour être sur une « page », mais d'avoir de nombreuses sections Bookmarkable qui respectent le bouton de retour. L'application doit changer l'ancre lorsqu'un utilisateur entre différents « états », et même si un utilisateur utilise le bouton de retour ou d'un signet ou un lien pour charger l'application avec un point d'ancrage inclus, l'application doit restaurer l'état approprié.

Alors là vous l'avez: Ancres fournir aux programmeurs Javascript avec un mécanisme pour faire bookmarkable, indexables et dos-bouton-friendly applications. Cette technique a un nom: Il est un

.

p.s. Il y a un quatrième avantage à cette technique: le contenu de la page de chargement par AJAX et l'injecter dans le DOM actuel peut être beaucoup plus rapide que le chargement d'une nouvelle page. En plus de l'augmentation de vitesse, d'autres tours comme le chargement de certaines parties de l'arrière-plan peuvent être effectués sous le contrôle du programmateur.

p.p.s. Compte tenu de tout cela, la marque « bang » ou d'exclamation est un autre indice pour le robot d'exploration Web de Google que l'exacte même page peut être chargée à partir du serveur à une URL légèrement différente. Voir Ajax Crawling . Une autre technique consiste à faire de chaque point de lien vers une URL du serveur accessible et ensuite utiliser Javascript discret pour le transformer en un SPI avec une ancre.

Voici le lien touche: Le Manifeste Interface Page simple

Answer 3

D'abord: Je suis l'auteur du The Single page Interface Manifeste citée par raganwald

Comme raganwald a très bien expliqué, l'aspect le plus important de l'approche unique page Interface (SPI) utilisé dans FaceBook et Twitter est l'utilisation de # de hachage dans les URL

Le ! de caractère est ajouté uniquement à des fins Google, cette notation est un "standard" Google pour l'analyse de sites web intensif sur AJAX (dans les extrêmes sites Web Interface Page simple). Lorsque le robot d'exploration de Google trouve une URL avec #! il sait qu'une URL classique alternative existe en offrant la même page « état », mais dans ce cas, le temps de chargement.

Malgré combinaison #! est très intéressant pour le référencement, est pris en charge par Google (en ce que je sais), avec quelques astuces JavaScript, vous pouvez construire SPI sites Web SEO compatibles pour tout crawler web (Yahoo, Bing ...) .

Le Manifeste SPI et démos ne pas utiliser le format de Google de ! hashs, cette notation pourrait être facilement ajoutée et rampants SPI pourrait être encore plus facile (MISE A JOUR: maintenant la notation est utilisée et reste compatible avec les autres moteurs de recherche).

Jetez un oeil à cette tutoriel , est un exemple d'un simple site ItsNat SPI, mais vous pouvez choisir des idées pour d'autres cadres, cet exemple est compatible SEO pour tout web crawler.

Le problème difficile est de générer un (ou sélectionné) « état page AJAX » comme HTML brut pour le référencement, en ItsNat est très facile et automatique, le même site est dans le même temps SPI ou page basée pour le référencement (ou lorsque JavaScript est désactivé pour l'accessibilité). Avec d'autres cadres web, vous pouvez toujours suivre la double approche du site, un site est basé SPI et une autre page basée pour le référencement, par exemple Twitter utilise cette technique « double site ».

Answer 4

Je serais très prudent si vous envisagez d'adopter cette convention Hashbang .

  

Une fois que vous Hashbang, vous ne pouvez pas revenir en arrière. Ceci est probablement la question plus épineux. poste de Ben a présenté le point que lorsque pushState est plus largement adopté alors nous pouvons laisser hashbangs derrière et revenir aux URL traditionnelles. Eh bien, fait est, vous ne pouvez pas. Plus tôt je l'ai dit que les URL sont toujours, ils sont indexés et archivés et conservés généralement autour. Pour ajouter à cela, les URL fraîches ne changent pas. Nous ne voulons pas nous déconnecter de tous les liens utiles à notre contenu. Si vous avez mis en place des URL Hashbang à tout moment que vous voulez les changer sans liens briser la seule façon que vous pouvez le faire est en exécutant un JavaScript sur le document racine de votre domaine. Pour toujours. Il est en aucun cas temporaire, vous êtes coincé avec elle.

Vous voulez vraiment utiliser pushState au lieu de hashbangs , parce que faire vos URL laid et peut-être brisée - pour toujours -. est un inconvénient colossal et permanent à hashbangs

Answer 5

Pour avoir un bon suivi de tout cela, Twitter - l'un des pionniers de URL de Hashbang et une seule page interface - a admis que le système Hashbang a été lent à long terme, et qu'ils ont effectivement commencé à revenir sur la décision et le retour aux liens de la vieille école.

article à ce sujet est ici.

Answer 6

J'ai toujours supposé le ! juste indiqué que le fragment de hachage qui a suivi correspond à une URL, avec ! prenant la place de la racine ou d'un domaine site. Il pourrait être quelque chose, en théorie, mais il semble l'API Google AJAX Crawling aime cette façon.

Le hachage, bien sûr, tout indique qu'aucun rechargement de la page réelle se produit, alors oui, il est à des fins AJAX. Edit:. Raganwald fait un travail très agréable expliquant plus en détail

Answer 7

Les réponses ci-dessus décrivent bien pourquoi et comment il est utilisé sur twitter et facebook, ce qui m'a manqué est ce que l'explication # fait par défaut ...

Sur un « normal » (pas une seule application page) vous pouvez faire avec ancrage hash à tout élément qui a id en plaçant cet identifiant éléments dans l'URL après # de hachage

Exemple:

(Chrome) Cliquez sur F12 ou rihgt souris et Inspect element

puis prendre id="answer-10831233" et ajouter à l'url suivante

https://stackoverflow.com/questions/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233

et vous obtiendrez un lien qui saute à cet élément sur la page

Quel est le tralala / Hashbang (#!) dans Facebook et Twitter pour les nouvelles URL

En utilisant # d'une manière décrite dans les réponses ci-dessus vous présentez un comportement conflictuel ... bien que je ne dormirais pas lâche dessus ... depuis angulaire, il est devenu en quelque sorte une norme ....