Bonnes raisons de ne pas utiliser les iframes dans le contenu des pages
Ok, je cherche donc de bonnes raisons pour ne pas utiliser les iFrames dans le contenu des pages. Mon ami qui souhaite utiliser un iFrame pour notre chatbox et charger une page html au lieu d'utiliser simplement ajax pour charger les paramètres nécessaires et interroger longuement la demande. Une fois que nous avons nos paramètres, nous remplissons ensuite quelques divs avec notre contenu.
Mes plus grandes raisons
Pourquoi charger deux pages simultanément
Plus de codage est nécessaire pour injecter dans l'iFrame
Quelqu'un connaît-il d'autres conflits et problèmes possibles qui pourraient survenir? Je sais qu'il y a quelque temps, les iFrames étaient censées être obsolètes, puis elles ont fait un bond en arrière sur les sites Web.
ps Je ne savais pas si cela devait aller dans SO ou MSO si besoin est je peux le déplacer
Source: http://www.rwblackburn.com/2012/07/iframe-evil/
Il semble donc que chaque travail sur lequel je travaille, le même sujet se pose. Quelqu'un, à un moment donné, dira: "utilisez simplement un iFrame pour cela". Ensuite, je dois emprunter la vieille route fatiguée pour savoir pourquoi ce ne serait pas une bonne idée.
Eh bien, cet article va être un peu utilitaire pour moi. J'espère mettre en un seul endroit toutes les raisons pour lesquelles les iFrames ne sont pas une solution universelle pour que je puisse gagner du temps à l'avenir et simplement pointer les gens vers cette URL. En tant que tel, je peux mettre à jour ce message à l'occasion en affinant ces points. N'hésitez pas à utiliser ce message dans le même but si vous le souhaitez, et veuillez publier toutes les suggestions ou points que j'ai manqués sur mon compte Twitter (@rwbDev), je serai sûr de vous remercier si j'ajoute le point à cet article.
Maintenant, permettez-moi d'être clair. Les iFrames ont un objectif valide. J'ai moi-même utilisé plusieurs fois iFrames avec beaucoup de succès. Le problème est que les gens ont tendance à vouloir les utiliser pour contourner une architecture médiocre ou simplement pour résoudre un problème. D'après mon expérience, cela échange généralement un petit problème contre un problème beaucoup plus important sur la route, et le plus souvent, c'est un compromis inutile. Je couvrirai ces deux points ci-dessous.
Mauvais pour le référencement. C'est l'une des raisons les plus courantes pour éviter les iFrames. Certains moteurs de recherche peuvent rencontrer des difficultés avec les pages référencées dans les iFrames. On ne sait pas dans quelle mesure cela affecte le classement de recherche d'un site ou d'une page. Cependant, la plupart des experts avec qui j'ai parlé conviennent que cela a certainement un impact. Consultez ce formulaire intéressant sur le tropique. Pour plus de détails sur le fonctionnement du référencement et les impacts de décisions de conception comme celle-ci, je suggère de consulter seomoz.org. Ce n'est bien sûr pas un problème si le référencement n'est pas une préoccupation pour votre page ou application. Par exemple une application qui nécessite une connexion (toutes les pages derrière la connexion ne sont de toute façon pas accessibles aux moteurs de recherche). * Remarque (ajoutée le 6 juin 2013): Des tests récents ont montré que les moteurs de recherche peuvent en fait suivre les liens dans un iFrame. Cela signifie que l'impact SEO d'un iFrame est beaucoup moins important que par le passé. Il n'est pas encore clair qu'il n'y ait pas d'impact, et différents moteurs de recherche peuvent se comporter différemment à cet égard.
Liens/Signets. Sauf si vous introduisez du JavaScript supplémentaire, l'utilisateur ne pourra pas obtenir un lien directement vers le contenu dans l'iFrame. Cela inclut les liens que quelqu'un pourrait envoyer à un ami, des signets ou des pages qui apparaissent dans les résultats d'un moteur de recherche. Imaginez que votre utilisateur accède à votre page et que du contenu se trouve dans un iFrame. Ils cliquent sur un lien dans le contenu iFramed. Ce contenu restera dans l'iFrame comme prévu. Maintenant, vos utilisateurs trouvent du contenu vers lequel ils ont navigué dans l'iFrame et souhaitent l'envoyer à un ami. Mais la copie de l'URL dans leur navigateur ne fonctionnera pas, cela enverrait simplement l'ami à la page initiale, avec le contenu original affiché dans l'iFrame. Il existe des scripts qui peuvent contourner ce problème. Je les ai moi-même implémentées plusieurs fois (dans des situations où je n'avais pas le choix). Cependant, ceux-ci présentent souvent certains de leurs propres problèmes et ont souvent des problèmes de compatibilité entre les navigateurs. Souvent, c'est aussi un buggy en bas à droite. Encore une fois, selon votre site ou les besoins de votre application, cela peut ne pas être un problème, mais c'est un gros problème pour la plupart des sites.
Difficulté avec le débogage. C'est un problème que les gens ont souvent négligé. Si vous avez une application robuste avec jQuery, Ajax et d'autres trucs sympas qui se produisent partout sur la page - les iFrames peuvent rendre le débogage d'un problème beaucoup plus difficile. L'erreur se produit-elle dans la page externe ou la page dans le cadre? Les outils de développement du navigateur peuvent vous y aider, mais même ces outils ne permettent pas toujours de savoir clairement où se situe le problème lorsque vous traitez un iFrame. Vous seriez surpris de la fréquence à laquelle un bogue peut être répliqué lorsqu'une page se trouve dans un iFrame, mais fonctionne très bien lorsqu'il est chargé en dehors de l'iFrame. C'est un problème pour n'importe quel site. Mais surtout pour les sites qui utilisent largement les iFrames. Plus il y a de pièces mobiles dans un système, plus il est difficile de diagnostiquer un problème.
Aucun gain de performances réel. De temps en temps, je trouverai quelqu'un qui souhaite utiliser un iFrame car il pense que cela augmentera les performances de son site. Ils se sentent généralement de cette façon, car cela évitera d'avoir à recharger l'en-tête/pied de page/menu du site chaque fois que le site pagine. Le plus souvent, l'inverse est vrai. En fait, d'après mon expérience, cela n'a jamais entraîné de gain de performances par rapport à la réparation de l'architecture de l'application. Tout d'abord, considérez que les navigateurs mettront en cache les images, les fichiers CSS et JS. Donc, ceux-ci ne se rechargeront pas de toute façon. Mais plus important encore, les gens qui pensent dans ce sens regardent souvent les iFrames comme s'ils étaient l'AJAX d'un pauvre. Cependant, le contenu d'une pagination iFrame sera presque toujours plus lourd qu'un véritable appel AJAX qui utilise XML ou JSON pour charger et actualiser uniquement une petite partie du contenu de la page.
Son tout simplement difficile à maintenir stable. Il y a un grand site d'un ancien travail à moi qui utilisait beaucoup iFrame. Je ne sais pas où le NDA s'applique ici, donc je ne lierai pas à leur site juste pour être sûr. Ils les utilisent souvent et ont tous les scripts et astuces de fantaisie utilisés (en théorie ) éviter les inconvénients normaux de l'utilisation d'iFrames. Cependant, il y a toujours des problèmes et des erreurs fréquentes sur leur site en raison de la mauvaise utilisation et de la surutilisation d'iFrame. le problème que cela leur a causé. Je viens de sauter sur leur site et en quelques minutes j'ai trouvé une page qui m'a donné une erreur en raison d'un problème avec iFrame. Ce sont des gens intelligents qui connaissent bien les problèmes avec les iFrames. Pourtant, même ils continuent à des années plus tard, lorsque les iFrames sont maltraitées comme elles le sont sur ce site, aucune quantité de scripts sophistiqués ne résoudra complètement les problèmes qui se poseront inévitablement.
les iframes ajoutent de la flexibilité au contexte de la page car ils constituent un moyen simple et fiable de séparer le contenu sur plusieurs pages. il peut également être utile de "sandboxer" des pages internes dans un iframe afin qu'un balisage pauvre/manquant n'affecte pas la page principale.
L'inconvénient est que si vous introduisez plusieurs couches de défilement (une pour le navigateur, une pour l'iframe), les utilisateurs seront frustrés.
Les raisons importantes sont:
- performances plus lentes.
- bloc Iframes
onloadévénement.
L'événement onload est principalement utilisé par les développeurs Web pour lancer des actions d'interface utilisateur, comme se concentrer sur les fichiers de connexion au chargement.
Certains navigateurs ne prennent pas en charge les iFrames, dans un iFrame, votre site Web peut contenir votre contenu, avec le contenu d'un autre site Web, mais le contenu peut changer à tout moment, en du matériel que vous pouvez approuver ou non.Certains problèmes comme Coûteux, même si Vide. Bloque la rémanence d'une page non désirée et non sémantique
Vous ne pouvez pas faire coopérer CSS entre IFrame et la page parent, à moins que vous ne contrôliez les feuilles de style elles-mêmes. Comme mentionné ci-dessus, il est vrai que-
Nous ne pouvons pas obtenir de bonnes performances en utilisant I Frame, Certains moteurs de recherche peuvent avoir des difficultés avec les pages référencées dans i Frames. On ne sait pas dans quelle mesure cela affecte le classement de recherche d'un site ou d'une page. Ma suggestion serait d'utiliser simplement toutes les autres options en premier. Ne vous contentez pas de passer à la solution iFrame car elle semble facile en surface.