Le JavaScript en ligne est-il bon ou mauvais?
Je suis actuellement passé de WordPress à framework Yii et un développeur externe est en train de reconstruire mon site.
Une chose que je remarque, c’est que chaque fois qu’il invoque AJAX/jQuery à la manière Yii, il intègre insère JavaScript en ligne dans la page web. Bien qu'il semble que le code JavaScript soit placé sous le pied de page, il est toujours en ligne.
En général, il semble que le code JavaScript soit plus fréquemment inséré dans la page Web. J'ai toujours pensé que les scripts JavaScript devraient, autant que possible, être placés dans des fichiers JavaScript. Est-ce une "nouvelle" tendance à venir? Ou devrais-je toujours essayer de conserver le code JavaScript dans des fichiers séparés?
JavaScript intégré augmente les temps de téléchargement de la page, ce qui n’est pas satisfaisant. Avec un appel à un fichier .js, il peut au moins s'agir d'appels en parallèle et d'une réduction du temps de téléchargement du contenu. Oui, il est parfois correct d'insérer JavaScript directement dans le code HTML, mais il est souvent préférable de le décharger autant que possible.
N'oubliez pas que les temps de téléchargement de page (c'est-à-dire le code HTML) et que tous les appels de ressources n'affectent pas les métriques qui affectent le classement (bien que le PageRank ou les SERP importent peu). Le fait est que cela affecte les performances des sites en matière de référencement, peu importe les circonstances.
Sur mon site de conversion de devises, la majorité des sessions sont des pages uniques. En effet, les utilisateurs peuvent effectuer leur calcul de devise directement sur la page de destination (tout le calcul est géré côté client avec JavaScript.)
Ma page se télécharge et s'affiche environ la moitié du temps que toutes les ressources (css, js et même images ) sont en ligne dans la page. Étant donné que très peu de mes utilisateurs consultent plusieurs pages, je ne tirerais pas grand profit de la mise en cache de certaines de ces ressources entre les affichages de pages.
Mon site n'est pas typique. La plupart des sites ont plusieurs pages par session et de grandes images qui rendraient ma technique moins applicable. Il n’existe pas de solution unique à cette question; cela dépend du site. Vous devez le mesurer vous-même en fonction du comportement typique de vos utilisateurs.
Ce n’est pas forcément mauvais d’avoir du JavaScript dans votre fichier HTML, mais vous devez faire appel à son jugement.
C’est est mauvais si vous utilisez une grande quantité de JavaScript sur plusieurs pages. Dans ce cas, le code JavaScript doit figurer dans un fichier externe compressé et cachable. Si votre site génère un trafic très important, vous devez utiliser un CDN.
Cependant, si vous avez une petite quantité de JavaScript, le fait de le placer dans un fichier externe peut être annulé par le fait que vous devez créer une requête HTTP supplémentaire pour le récupérer. Dans ce cas, il serait plus efficace de conserver le code JavaScript dans votre page.
Là encore, si ce même petit extrait de code JavaScript est utilisé sur plusieurs pages, il serait avantageux de le placer dans un fichier externe pour tirer parti de la mise en cache.
En fin de compte, vous devez évaluer la taille du code JavaScript par rapport à la charge supplémentaire liée à la création de requêtes HTTP supplémentaires. Pour la plupart, pour un site "moyen", cela ne fera probablement pas beaucoup de différence, mais le fait de le placer dans un fichier externe.
Je suis un Yii développeur et je peux vous dire que Yii n'a rien à voir avec cela . Il est complètement du côté du développeur , qu'il mette le code Javascript dans un fichier séparé et l'enregistre avec la page HTML (affichage) avec CClientScript::registerScriptFile méthode ou mettez-le directement pour afficher le code (HTML) et enregistrez-le à l'aide de la méthode CClientScript::registerScript .
Selon votre réponse, la plupart (professionnels?) Yii développeurs votent fortement pour la première approche, à savoir - conserver autant de code Javascript que possible dans des fichiers séparés. Donc, c’est certainement pas une nouvelle tendance en matière de codage, mais plutôt une mauvaise pratique pour les développeurs. Au moins, c'est comme cela que l'on voit dans la communauté Yii.
EDIT: En fait, j'ai oublié l'argument le plus important. Yii (ainsi que la plupart des autres frameworks professionnels PHP) repose sur MVC motif de conception (en fait: motif architectural). Et le même modèle peut être utilisé devant: code HTML est le modèle (données), CSS est la vue (décorateur) et Javascript est le contrôleur. Tous ont placé dans des fichiers séparés , _.js_ et _.css_ fichiers - minifiés, obsfucés et gzippés dans le meilleur scénario.
Lorsque vous construisez votre application Yii, vous pouvez casser le modèle MVC et tout conserver dans le même fichier. La question est de savoir si cela en vaut la peine, quels sont les avantages (aucun?) Et où cela vous mènera-t-il? Vous pouvez utiliser la même argumentation lorsque vous demandez si vous souhaitez conserver le code JS en ligne ou non.
Cela dépend en fait du but de la page Web que vous développez:
J'utilise une petite quantité de JavaScript en ligne, alors que je préfère les fichiers JavaScript externes si c'est gros.
Quoi qu'il en soit, lorsque la page charge du code JavaScript, il doit d'abord être exécuté. La meilleure pratique consiste à utiliser du JavaScript externe pour ne pas allonger le contenu de votre page. Cela facilite également le débogage.
La réponse dépend en fait de ce qui est fait.
Si vous remarquez que du code JavaScript intégré est utilisé sur le site Web (par exemple, un widget qui apparaît dans l'en-tête de toutes les pages du site Web), il convient de le déplacer dans un fichier JavaScript "commun".
En fait, je déplacerais autant de JavaScript que possible vers un fichier JavaScript commun, même s'il était utilisé sur une seule page. Je configurerais le serveur pour envoyer des en-têtes de compression et de cache puissants pour les fichiers JavaScript; ce qui réduit la taille des pages mais n'augmente pas de beaucoup la taille du fichier JavaScript.
Par contre, si le JavaScript est simplement un groupe d’options de configuration/d’initialisation, par exemple:
$(function () {
myplugin({
images: ["img1", "img2", "img3"]
});
});
où, pour une raison quelconque, il n’était pas possible de déplacer le code dans un fichier JavaScript externe (par exemple, lorsque les paramètres de l’image venaient de la base de données), je le gardais en ligne. Cela dit, je choisirais des plugins tiers "discrets" (ou les convertirais en tant que tels).
Ces réponses manquent la cible. Jetez un oeil à Inline Caching .
Puisque Yii est codé en PHP, vous constaterez qu'un motif courant (ou peut-être peu commun) PHP est que les développeurs écrivent parfois du code PHP pour générer du code Javascript. dynamiquement sur le serveur - en fonction d'un état, d'une condition ou d'une valeur connue du serveur - puis de tout envoyer au client en un seul lot, permettant ainsi au client d'exécuter la fonction et d'ignorer une partie du calcul déjà effectué par le serveur.
Au lieu d'envoyer toute une série de fonctions Javascript génériques dans un fichier .js au client, qui n'ont pas de contexte jusqu'à ce qu'elles soient fournies avec des données contexte/données dans le cadre de la fonction Javascript. C'est économe parce que cela signifie que vous envoyez la fonctionnalité/les données ensemble et que vous n'envoyez que la fonctionnalité/les données dont un client peut avoir besoin à ce moment-là, au lieu d'envoyer l'intégralité de l'application au chargement de la première page. Cela signifie également que vous n'avez pas à exposer l'intégralité de votre application à un téléchargement facile et à une ingénierie inverse au premier chargement de la page, car vous n'injectez que de petites portions des fonctionnalités dont chaque client peut avoir besoin à ce moment-là. Je ne sais pas à quel point cela est de bon augure pour le référencement, mais je suis sûr que cela peut être optimisé en conséquence. Réduire le nombre de requêtes HTTP en utilisant du Javascript intégré peut être utile, cela dépend.
Prenons le cas d'un utilisateur final qui écrit une page dans un logiciel CMS à l'aide d'un éditeur WYSIWYG. Comment cet utilisateur va-t-il ajouter de nouvelles fonctionnalités à la page quand il n'a pas accès à vos fichiers source .js sur le serveur? Ils basculent vers l'onglet HTML et utilisent le Javascript en ligne.
Tout le Javascript en ligne n'est pas mauvais; parfois onclick est bien aussi. En règle générale, évitez d'écrire du code Javascript en ligne et vous serez sur la bonne voie pour créer de bonnes habitudes.
Références:
Normalement, le code JS en ligne est mauvais, comme l'ont dit les autres avant moi.
Mais je pense à un cas d'utilisation où JS en ligne est mieux.
Pensez à un CMS qui insère une galerie pilotée par JS. La galerie peut-être faite en jQuery. Il est identifié par un attribut id, non seulement unique sur la page, mais également unique sur l'ensemble du site. Dans ce cas, je pense que JS intégré serait préférable, car le code JS n'est utilisé que sur une page et que vous n'avez pas de surcharge HTTP.