Quels sont les détails techniques que le programmeur d'une application web doit prendre en compte avant de rendre le site public ?
Quels sont les éléments qu'un programmeur chargé de mettre en œuvre les détails techniques d'une application web doit-il prendre en compte avant de rendre le site public ? Si [Jeff Atwood][1] peut oublier les [cookies HttpOnly][2], les [sitemaps][3], et les [cross-site request forgeries][4] tous dans le même site, quelle chose importante pourrais-je oublier moi aussi ?
Je pense à cela du point de vue d'un développeur web, c'est-à-dire que quelqu'un d'autre crée la conception et le contenu du site. Ainsi, si la convivialité et le contenu peuvent être plus importants que la plate-forme, vous, le programmeur, n'avez pas grand-chose à dire à ce sujet. Ce dont vous devez vous préoccuper, c'est que votre mise en œuvre de la plate-forme soit stable, performante, sécurisée et qu'elle réponde à d'autres objectifs commerciaux (comme ne pas coûter trop cher, ne pas prendre trop de temps à construire et être aussi bien classé dans Google que le contenu le permet).
Voyez cela du point de vue d'un développeur qui a travaillé sur des applications de type intranet dans un environnement relativement fiable, et qui est sur le point d'avoir sa première chance de mettre en place un site potentiellement populaire pour l'ensemble du grand méchant web mondial.
De plus, je cherche quelque chose de plus spécifique qu'une vague réponse de type " normes Web ". Je veux dire que le HTML, le JavaScript et le CSS sur HTTP sont pratiquement une évidence, surtout si j’ai déjà précisé que vous êtes un développeur web professionnel. Mais au-delà de ça, quelles sont les normes ? Dans quelles circonstances, et pourquoi ? **Fournissez un lien vers la spécification de la norme.
[1] : https://softwareengineering.stackexchange.com/users/37/jeff-atwood [2] : http://www.codinghorror.com/blog/archives/001167.html [3] : http://www.codinghorror.com/blog/archives/001174.html [4] : http://www.codinghorror.com/blog/archives/001171.html
L'idée est que la plupart d'entre nous devraient déjà connaître la plupart des éléments de cette liste. Mais il se peut qu'il y ait un ou deux éléments que vous n'avez pas vraiment examinés auparavant, que vous ne comprenez pas entièrement ou dont vous n'avez peut-être même jamais entendu parler. Interface et expérience utilisateur
rel="nofollow"aux liens créés par les utilisateurs [pour éviter le spam][12].rel="noopener noreferrer"sur tous les liens fournis par l'utilisateur avectarget="_blank"pour empêcher JavaScript sur la page de destination de rediriger votre page vers un autre endroit, comme une fausse page de connexion. Plus d'informationsfavicon.icoà la racine du site, c'est-à-dire/favicon.ico. [Les navigateurs le demanderont automatiquement] (http://mathiasbynens.be/notes/rel-shortcut-icon), même si l'icône n'est pas du tout mentionnée dans le code HTML. Si vous n'avez pas de/favicon.ico, il en résultera un grand nombre de 404, qui épuiseront la bande passante de votre serveur. SEO (optimisation pour les moteurs de recherche)#pour du contenu dynamique, changez le#en#!et ensuite sur le serveur$_REQUEST["_escaped_fragment_"]est ce que googlebot utilise à la place de#!. En d'autres termes,./#!page=1devient./?_escaped_fragments_=page=1. De plus, pour les utilisateurs qui utilisent FF.b4 ou Chromium,history.pushState({"foo" : "bar"}, "About", "./?page=1");est une excellente commande. Ainsi, même si la barre d'adresse a changé, la page ne se recharge pas. Cela vous permet d'utiliser?au lieu de#!pour conserver un contenu dynamique et aussi de dire au serveur lorsque vous envoyez le lien par courriel que nous sommes après cette page, et l'AJAX n'a pas besoin de faire une autre requête supplémentaire./sitemap.xml.301 Moved Permanently) demandantwww.example.comversexample.com(ou l'inverse) pour éviter de diviser le classement google entre les deux sites.