Le JavaScript en ligne est-il bon ou mauvais?

16

Je suis actuellement passé de WordPress au framework Yii et un développeur externe reconstruit mon site.

Une chose que je remarque, c'est qu'à chaque fois qu'il invoque AJAX / jQuery à la manière Yii, il insère des inserts 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 dois-je quand même essayer de conserver le code JavaScript dans des fichiers séparés?

html javascript Steven
la source
Que voulez-vous dire exactement par l'insertion de JavaScript en ligne dans la page Web ?
Salman A
3
Pour le bien des autres qui trouvent cette question et pensent à des choses comme ça <a onClick="function(){/* do stuff */} ">Click Here</a>, je comprends, est considérée comme TRÈS mauvaise et il faut séparer leur code de leur HTML Voir: Cet article
TecBrat
1
@ user1066946 t.co/j1RpJgwoku :-)
Kos
1
@ user1066946 J'aime vraiment utiliser Angular, je viens de remarquer que le "web sémantique" a fait un cercle (en termes de garder du code de colle à côté du DOM)
Kos
1
"Bien qu'il semble que le code JavaScript soit placé sous le pied de page, il est toujours en ligne." - Il semble que vous vous référiez au JavaScript intégré , plutôt qu'au JavaScript "en ligne" (auquel TecBrat fait référence).
MrWhite

Réponses:

13

JavaScript en ligne augmente les temps de téléchargement de la page, ce qui n'est pas bon. Avec un appel à un .jsfichier, il peut s'agir au moins d'appels parallèles et de temps de téléchargement de contenu réduits. Oui, il y a des moments où il est correct de mettre JavaScript directement dans le code HTML, mais il est souvent préférable de le décharger autant que possible.

Gardez à l'esprit que les temps de téléchargement des pages (c'est-à-dire le HTML) et que tous les appels de ressources n'affectent pas les métriques qui affectent le classement (bien que comme PageRank ou dans les SERP, cela n'a pas d'importance). Le fait est que cela affecte les performances d'un site pour le référencement, mais cela se manifeste.

placard
la source
7
Négocier une deuxième connexion à un même hôte vraisemblablement pour télécharger la même quantité de données est plus rapide que dans le flux actif? généralement, si vous obtenez, disons, 50 Kbps sur un fichier vers un hôte, le démarrage d'une deuxième session peut le couper de sorte que les deux sont maintenant à 25 Kbps. Sauf si l'hôte limite par connexion pour une raison quelconque.
EkriirkE
Il y a cependant un inconvénient aux fichiers externes. Si cela n'est pas fait correctement, vous créez du code DOMblocking, c'est-à-dire que le déclencheur doc.ready est plus lent, ce qui affecte la vitesse perçue . Mais si c'est fait correctement, l'externe est la voie à suivre
Martijn
4
.jsles fichiers sont meilleurs pour la mise en cache, il n'est pas logique que deux connexions au même hôte augmentent par magie votre vitesse de téléchargement.
L'idée de diviser la bande passante, même si je comprends votre logique et qu'elle n'est pas entièrement fausse, est un peu trompeuse. Le code HTML est plus petit, ce qui prend moins de temps et tout appel ultérieur peut réellement attendre.
closetnoc
3
si vous cherchez du temps, vous avez tort de regarder la bande passante. regardez le profileur aux heures de chargement: normalement les temps de connexion sont 10-100x PLUS GRANDS que le temps réel d'échange de données. cela signifie que la FRAGMENTATION est un vrai problème, et utiliser un fichier externe dédié pour de très petits js peut être pire que celui en ligne. Inline est meilleur sur un navigateur qui ne fait pas de véritable parallélisation
Lesto
29

Sur mon site de conversion de devises, la majorité des sessions sont vues sur une seule page. 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 dans environ la moitié du temps lorsque toutes les ressources (css, js et même les images ) sont en ligne dans la page. Parce que si peu de mes utilisateurs consultent plusieurs pages, je ne bénéficierais pas beaucoup de la mise en cache de certaines de ces ressources entre les pages vues.

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'y a pas de solution correcte à cette question; cela dépend du site. Vous devez le mesurer vous-même en fonction du comportement typique de vos utilisateurs.

Stephen Ostermiller
la source
12

Ce n'est pas nécessairement mauvais d'avoir JavaScript dans votre fichier HTML mais vous devez faire un jugement.

Il est mauvais si vous avez une grande quantité de JavaScript utilisé sur plusieurs pages. Dans ce cas, le JavaScript doit être dans un fichier externe, compressé et cachable et si votre site a un trafic très important, vous devez utiliser un CDN.

Cependant, si vous avez une petite quantité de JavaScript, l'enregistrement de le placer dans un fichier externe peut être annulé par le fait que vous devez effectuer une demande HTTP supplémentaire pour le récupérer. Dans ce cas, il serait plus efficace de conserver le JavaScript dans votre page.

Là encore, si ce même petit extrait de JavaScript est utilisé sur plusieurs pages, il serait avantageux de le placer dans un fichier externe pour profiter de la mise en cache.

En fin de compte, vous devez peser la taille du JavaScript par rapport à la charge supplémentaire liée aux requêtes HTTP supplémentaires. Pour la plupart, pour un site «moyen», cela ne fera probablement pas beaucoup de différence simplement en le plaçant dans un fichier externe.

écume
la source
4

Je suis un développeur Yii et je peux vous dire que Yii n'a rien à voir avec cela . C'est complètement du côté du développeur , qu'il ou elle mette du code Javascript dans un fichier séparé et l'enregistre avec la page HTML (affichage) avec la CClientScript::registerScriptFileméthode ou le mette directement pour afficher le code (HTML) et l'enregistre en utilisant la CClientScript::registerScriptméthode.

Selon votre réponse, la plupart des développeurs (professionnels?) De Yii votent fortement pour la première approche, c'est-à-dire en conservant autant de code Javascript que possible dans des fichiers séparés. Donc, ce n'est certainement pas une nouvelle tendance de codage, mais plutôt une mauvaise pratique de développeur. Du moins, c'est ainsi que cela se voit dans la communauté Yii.

EDIT : En fait, j'ai oublié l'argument le plus important. Yii (ainsi que la plupart des autres frameworks PHP professionnels) est construit sur un modèle de conception MVC (en fait: un modèle architectural). Et le même modèle peut être utilisé en façade: le code HTML est le modèle (données), CSS est la vue (décorateur) et Javascript est le contrôleur. Tous mis dans des fichiers séparés , .jset des .cssfichiers - minifiés, obsolètes et compressés dans le meilleur scénario.

Lorsque vous créez votre application Yii, vous pouvez rompre le modèle MVC et tout garder dans le même fichier. La question est - cela vaut-il 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?

trejder
la source
D'accord. Le développeur semble utiliser des widgets tiers pour tout; Autocomplete, téléchargement d'images ajax, etc. Tout cela ajoute des js en ligne.
Steven
Non, je ne peux pas être d'accord. J'utilise Twitter Bootstrap dans mes applications Yii (probablement la plus grande extension de Yii et un énorme ensemble de widgets) ainsi que de nombreuses autres extensions de Yii et aucune d'entre elles n'utilise JS en ligne. Votre développeur devrait être vraiment chanceux de trouver des widgets et des extensions, qui utilisent uniquement du Javascript en ligne. Vous devez être assez expérimenté dans Yii pour commencer à écrire vos propres extensions (à l'exception de ces quelques-unes, vraiment mal écrites) et même un développeur Yii semi-expérimenté utilise le code en ligne comme dernière option, si tout le reste échoue.
trejder
L'utilisation d'extensions et de widgets tiers dans Yii est une excellente idée (vous n'avez pas à réinventer la roue). Mais, utiliser du code JS en ligne dans une application ou une extension Yii est vraiment une mauvaise attitude. Alors forcez votre développeur à écrire un meilleur code / utilisez de meilleures extensions et widgets ou ... obtenez un meilleur développeur! :]
trejder
D'accord, merci pour les commentaires. Outre Stackoverflow, où puis-je trouver une bonne communauté Yii?
Steven
Au forum Yii . La plupart des pages sont librement accessibles. Certains nécessitent d'enregistrer un compte et de se connecter. La plupart des développeurs Yii de Stack Overflow ont leurs propres comptes sur le forum. Après près de six ans d'existence, le framework Yii a gagné une grande communauté de développeurs, donc si vous regardez attentivement, vous devriez pouvoir trouver quelques développeurs Yii dans votre communauté locale ou même dans votre quartier. Bonne chance.
trejder
3

Cela dépend en fait de l'objectif de la page Web que vous développez:

J'utilise une petite quantité de JavaScript en ligne, alors que je préfère opter pour des fichiers JavaScript externes si c'est gros.

Dans les deux cas, lorsque la page charge JavaScript, elle doit d'abord être exécutée. La meilleure pratique consiste à utiliser du JavaScript externe afin de ne pas allonger le contenu de votre page. Cela facilite également le débogage.

Abhijith Bhattu
la source
2

La réponse dépend en fait de ce qui se fait.

Si vous remarquez du code JavaScript intégré utilisé sur le site Web (par exemple, un widget qui s'affiche à l'intérieur de l'en-tête sur toutes les pages du site Web), il serait approprié de le déplacer vers 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 mise en cache et de compression puissants pour les fichiers JavaScript; ce qui réduit la taille des pages mais n'augmente pas beaucoup la taille du fichier JavaScript.

D'un autre côté, si le JavaScript est simplement un tas d'options de configuration / initialisation, par exemple:

$(function () {
    myplugin({
        images: ["img1", "img2", "img3"]
    });
});

où, pour une raison quelconque, il n'était pas possible de déplacer le code vers un fichier JavaScript externe (par exemple, lorsque les paramètres d'image proviennent de la base de données), je le garderais en ligne. Cela dit, je choisirais des plugins tiers qui sont "discrets" (ou les convertir en tant que tels).

Salman A
la source
2

Ces réponses manquent la cible. Jetez un œil à la mise en cache en ligne .

Étant donné que Yii est codé en PHP, un modèle PHP commun (ou peut-être inhabituel) que vous trouverez est que les développeurs écrivent parfois du code PHP pour générer dynamiquement du code Javascript sur le serveur - en fonction d'un état, d'une condition ou d'une valeur connue par le serveur - puis envoyez tout cela au client en un seul lot, ce qui permet au client d'exécuter la fonction et d'ignorer une partie du calcul qui a déjà été effectué par le serveur.

Au lieu d'envoyer tout un tas de fonctions Javascript génériques dans un fichier .js au client qui n'ont aucun contexte jusqu'à ce qu'elles reçoivent des données (données qui peuvent se trouver sur le serveur et nécessiter un aller-retour), nous pouvons "incorporer" le contexte / données dans le cadre de la fonction Javascript. C'est économe car cela signifie que vous envoyez les fonctionnalités / données ensemble, et que vous n'envoyez que les fonctionnalités / données dont un client peut avoir besoin à la fois, au lieu d'envoyer l'ensemble de l'application lors du premier chargement de la page. Cela signifie également que vous n'avez pas à exposer l'intégralité de votre application au téléchargement et à l'ingénierie inverse lors du premier chargement de page, car vous n'injectez que de petites portions de fonctionnalités dont chaque client individuel peut avoir besoin à la fois. Je ne sais pas à quel point cela augure pour le référencement, mais je suis sûr qu'il peut être optimisé en conséquence.

Prenons le cas d'un utilisateur final écrivant une page dans certains logiciels CMS à l'aide d'un éditeur WYSIWYG. Comment cet utilisateur va-t-il ajouter de nouvelles fonctionnalités à la page lorsqu'il n'a pas accès à vos fichiers .js source sur le serveur? Ils passent à l'onglet HTML et utilisent Javascript en ligne.

Tout Javascript en ligne n'est pas mauvais; parfois onclick est très bien aussi. En règle générale, évitez d'écrire en ligne Javascript et vous serez sur la bonne voie pour développer de bonnes habitudes.

Les références:

poiré
la source
0

Normalement, le code JS en ligne est mauvais, comme les autres l'ont dit avant moi.

Mais je pense à un cas d'utilisation où le JS en ligne est meilleur .

Pensez à un CMS qui insère une galerie pilotée par JS. La galerie peut être réalisée dans jQuery. Il est identifié par un attribut id, qui est non seulement unique sur la page, mais également unique sur l'ensemble du site. Dans ce cas - je pense - JS en ligne serait mieux, car le code JS est utilisé uniquement sur une seule page et vous n'avez pas de surcharge HTTP

yunzen
la source