C'est une bonne nouvelle ! Car si AMP était en soi une initiative intéressante, en faire un critère pour savoir si un site devait être mis en avant ou non dans les résultats de recherche constituait un réel problème. En effet, bien que cette solution soit ouverte, reposant sur des standards du web, elle était surtout poussée par Google qui se retrouvait à nouveau à favoriser l'une de ses initiatives, plutôt que d'évaluer l'efficacité et la pertinence des sites.
Dans l'évolution à venir, qui n'est pas encore datée, AMP sera utilisé pour l'affichage d'une page sur mobile lorsqu'il sera disponible, mais rien de plus. Ainsi, le carrousel pourra accueillir des pages n'utilisant pas ce format. De manière plus générale, les « Core Web Vitals » annoncés il y a peu seront également pris en compte désormais.
Il s'agit de trois éléments désormais analysés et considérés comme essentiels à une bonne « expérience » : le temps de chargement (LCP devant être inférieur à 2,5 s), l'interactivité (FID devant être inférieur à 100 ms), et la stabilité (CLS, devant être inférieur à 0,1). Des points mesurables à travers les outils comme le Chrome User Experience Report, PageSpeed Insights ou le Core Web Vitals report de la Search Console.
Bien entendu, ils ne font que s'ajouter aux autres critères déjà en place, comme le fait d'être accessible via HTTPS, adapté au mobile, sans publicités intrusives (selon les critères pris en compte par Google tout du moins), etc.
Commentaires (10)
#1
Un autre site (de Google) très pratique pour tester la performance d’un site:https://web.dev/
(en plus l’adresse est facile à retenir)
#2
Sauf que c’est déjà trop tard, une fois que google a annoncé privilégier AMP beaucoup de sites ont du sauter le pas ou au moins étudier AMP pour ne pas perdre un référencement vital…
#3
ça serait pas mal qu’ils y ajoutent le fait d’avoir implémenté DNSSEC sur le nom de domaine.
C’est typiquement le genre de mesure qui pourrait faire progresser pour la sécurité du Web et d’Internet en général, sans devoir passer par du DoH
Parce que personnellement, je trouve que c’est une aberration technique de faire passer de la résolution de noms par du HTTPS alors qu’il existe d’autres procotoles faits pour ça, mais ce n’est que mon avis ^^
EDIT : Google semble plutot promouvoir le DoT en fait
 https://en.wikipedia.org/wiki/DNS_over_TLS
#4
De ce que j’ai compris du DNSSEC, ça permet “seulement” de s’assurer l’intégrité du nom de domaine renvoyé par le serveur DNS (on est sûr que le serveur a bien envoyé ça et que personne n’a pu le modifier sur le parcours).
Cela ajoute de la sécurité il est vrai mais ça ne répond pas à la problématique de confidentialité des données : on peut voir quels noms de domaines tu as voulu connaître et donc quels sites tu as voulu visiter.
DoH apporte une réponse à cette problématique c’est pourquoi il a le vent en poupe en ce moment.
Aprés je te rejoins sur le fait que ce n’est pas très “propre” de dévier HTTP de son but initial. L’idéal serait un protocole DNSS à l’instar du HTTPS qui chiffrerait l’envoi d’un nom de domaine en plus d’assurer son intégrité.
#5
Genre DNScrypt ?
Ça fait bien de années que je n’utilise que ça.
#6
#7
#8
Effectivement ça semble correspondre à ce que j’imaginais.
#9
Je rajouterais un élement aux problèmes que tu présentes : je suis pas certain que les FAI traditionnels ainsi que le gouvernement soient chauds pour mettre en place cela. Je fais référence à la tendance générale à une surveillance accrue sur le web afin de mieux faire appliquer le droit
#10
sur mon PC du boulot, l’employeur intercepte le traffic SSL et remplace le certificat original par un autre
et le navigateur n’y voit que du feu … comment est-ce possible ? ça veut dire que SSL n’est pas du tout aussi sécurisé que cela puisqu’on peut changer le certificat en cours de route et le navigateur ne le voit même pas