À quoi servent le Shebang / hashbang (#!) De Facebook et les nouvelles URL de Twitter?
Je viens de remarquer que les URL longues et compliquées de Facebook que nous connaissons maintenant ressemblent à ceci:
http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345
Autant que je me souvienne, au début de l'année, il ne s'agissait que d'une chaîne normale ressemblant à un fragment d'URL (commençant par #), sans le point d'exclamation. Mais maintenant, c'est un Shebang ou un hashbang (#!), que je n'avais vu auparavant que dans les scripts Shell et les scripts Perl.
Les = nouveaux Twitter URL comportent désormais é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 spécial dans les URL, comme pour un certain framework Ajax ou quelque chose du genre, puisque les nouvelles interfaces Facebook et Twitter sont maintenant largement Ajaxified? Est-ce que l’utilisation de ceci dans mes URL profiterait à mon application Web?
Cette technique est maintenant obsolète .
Cela permettait à d'indiquer à Google comment indexer la page.
https://developers.google.com/webmasters/ajax-crawling/
Cette technique a principalement été supplantée par la possibilité d'utiliser l'API d'historique JavaScript introduite parallèlement à HTML5. Pour une URL telle que www.example.com/ajax.html#!key=value, Google vérifie l'URL www.example.com/ajax.html?_escaped_fragment_=key=value pour extraire une version du contenu non AJAX.
L'octothorpe/nombre-signe/hachage 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 que vous pouvez accéder aux sections du document avec une ancre, telles que:
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 basées sur Javascript (comme le mien Wood & Stones ) utilise des ancres est qu'ils veulent créer des pages avec des signets (comme suggéré par un commentaire sur cette réponse) ou soutenir le bouton de retour sans recharger la page entière du serveur .
Afin de prendre en charge les signets et le bouton Précédent, vous devez modifier l'URL. Toutefois, si vous modifiez la partie de la page (avec quelque chose comme window.location = 'http://raganwald.com';) en une URL différente ou sans spécifier d'ancrage, le navigateur chargera la page entière à partir de l'URL. Essayez ceci dans Firebug ou la console Javascript de Safari. Charger http://minimal-github.gilesb.com/raganwald. Maintenant dans la console Javascript, tapez:
window.location = 'http://minimal-github.gilesb.com/raganwald';
Vous verrez la page s'actualiser à partir du serveur. Maintenant tapez:
window.location = 'http://minimal-github.gilesb.com/raganwald#try_this';
Aha! Aucune actualisation de page! Type:
window.location = 'http://minimal-github.gilesb.com/raganwald#and_this';
Toujours pas de rafraîchissement. Utilisez le bouton Précédent pour vérifier que ces URL figurent dans l'historique du navigateur. Le navigateur remarque que nous sommes sur la même page mais que nous modifions simplement l'ancre afin de ne pas recharger. Grâce à ce comportement, nous pouvons avoir une seule application Javascript qui apparaît au navigateur comme étant sur une "page" mais comportant de nombreuses sections pouvant être marquées d'un signet respectant le bouton Précédent. L'application doit changer l'ancre lorsqu'un utilisateur entre différents "états". De même, si un utilisateur utilise le bouton de retour ou un signet ou un lien pour charger l'application avec une ancre incluse, l'application doit restaurer l'état approprié.
Donc, voilà: les ancres fournissent aux programmeurs Javascript un mécanisme permettant de créer des applications faciles à marquer, indexables et faciles à utiliser. Cette technique a un nom: C’est un Single Page Interface .
p.s. Cette technique présente un quatrième avantage: charger le contenu de la page via AJAX, puis l'injecter dans le DOM actuel peut être beaucoup plus rapide que le chargement d'une nouvelle page. Outre l'augmentation de la vitesse, d'autres astuces, telles que le chargement de certaines parties en arrière-plan, peuvent être exécutées sous le contrôle du programmeur.
p.p.s. Compte tenu de tout cela, le "coup" ou le point d'exclamation est un indice supplémentaire pour le robot d'exploration de Google que la 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 pointer chaque lien sur une URL accessible par le serveur, puis à utiliser du code Javascript non intrusif pour le transformer en SPI avec une ancre.
Voici à nouveau le lien clé: Manifeste de l'interface d'une seule page
Tout d’abord, je suis l’auteur du Manifeste sur l’interface à une seule page cité par raganwald.
Comme Raganwald l'a très bien expliqué, l'aspect le plus important de l'approche SPI (Single Page Interface) utilisée dans FaceBook et Twitter est l'utilisation de hash # dans les URL.
Le caractère ! est ajouté uniquement à des fins Google. Cette notation est une "norme" de Google pour l'exploration de sites Web nécessitant une utilisation intensive de AJAX (dans les sites Web à interface à une seule page extrêmes). Lorsque le robot d'exploration de Google trouve une URL avec #!, il sait qu'il existe une autre URL conventionnelle fournissant le même "état" de page, mais dans ce cas au moment du chargement.
En dépit de #! la combinaison est très intéressante pour le référencement, elle n’est supportée que par Google (pour autant que je sache), avec quelques astuces JavaScript vous pouvez construire SPI sites Web compatibles avec tous les robots d'exploration de Web ( Yahoo, Bing ...).
Le manifeste SPI et les démonstrations n'utilisent pas le format ! de Google dans les hachages, cette notation pourrait être facilement ajoutée et l'exploration de SPI pourrait être encore plus simple (UPDATE: now! Notation est utilisé et reste compatible avec les autres moteurs de recherche).
Jetez un oeil à ceci tutorial , est un exemple de site ItsNat SPI simple, mais vous pouvez choisir des idées pour d'autres frameworks, cet exemple est compatible SEO pour tout robot d'indexation.
Le problème difficile est de générer un "état de page AJAX" quelconque (ou sélectionné) en HTML simple pour le référencement. ItsNat est très simple et automatique, le même site est également dans le même temps SPI ou une page pour le référencement (ou lorsque JavaScript est désactivé pour l'accessibilité). Avec d'autres frameworks Web, vous pouvez toujours suivre l'approche de double site, un site est basé sur SPI et une autre page est basée sur le référencement, par exemple, Twitter utilise cette technique du "double site".
Je serais très prudent si vous envisagez d'adopter cette convention de hashbang.
Une fois que vous avez hash bang, vous ne pouvez plus revenir en arrière. C’est probablement le problème le plus épineux. Le message de Ben a mis en avant le fait que lorsque pushState est plus largement adopté, nous pouvons laisser le hashbangs derrière et revenir aux URL traditionnelles. En fait, c’est impossible. Un peu plus tôt, j'ai déclaré que les URL sont indéfinies, qu'elles sont indexées, archivées et généralement conservées. Pour ajouter à cela, les URLs sympas ne changent pas. Nous ne voulons pas nous déconnecter de tous les liens utiles vers notre contenu. Si vous avez implémenté des URL hashbang à un moment donné, vous souhaitez les modifier sans rompre les liens. La seule façon de le faire consiste à exécuter du code JavaScript sur le document racine de votre domaine. Pour toujours. Ce n’est pas temporaire, vous êtes coincé avec.
Vous voulez vraiment tiliser pushState au lieu de hashbangs , car rendre vos URL laides et éventuellement cassées - pour toujours - est un inconvénient colossal et permanent du hashbangs.
Pour faire un bon suivi de tout cela, Twitter - l'un des pionniers de l'URL de hashbang et de l'interface à page unique - a admis que le système de hashbang était lent à long terme et qu'ils avaient effectivement commencé à renverser la décision et à revenir à la page précédente. liens de la vieille école.
J'ai toujours supposé que le ! venait juste d'indiquer que le fragment de hachage qui suivait correspondait à une URL, avec ! prenant la place de la racine ou du domaine du site. En théorie, cela pourrait être n'importe quoi, mais il semble que l'API Google AJAX _ Crawling l'aime de cette façon.
Bien sûr, le hachage indique simplement qu’il n’ya pas de véritable rechargement de page, donc oui, c’est pour le but deAJAX. Edit: Raganwald fait un excellent travail en expliquant cela plus en détail.