Vous devez mettre votre code JS dans un fichier séparé car cela facilite le test et le développement. La question de savoir comment vous servez le code est une question différente.
Servir le HTML et le JS séparément a l'avantage qu'un client peut mettre en cache le JS. Cela vous oblige à envoyer des en-têtes appropriés afin que le client n'émette pas de nouvelle demande à chaque fois. La mise en cache est problématique si vous souhaitez effectuer une mise à jour et donc invalider les caches client. Une méthode consiste à inclure un numéro de version dans le nom de fichier, par exemple /static/mylibrary-1.12.2.js.
Si le JS est dans un fichier séparé, vous ne pouvez pas restreindre l'accès à celui-ci: il est difficile (techniquement: impossible) de dire si une demande à un fichier JS a été faite parce que vous l'avez référencé sur votre page HTML, ou parce que quelqu'un veut le télécharger directement. Vous pouvez cependant utiliser des cookies et refuser de servir des clients qui ne transmettent pas certains cookies (mais ce serait idiot).
Servir le JS à l'intérieur du HTML augmente la taille de chaque page - mais c'est OK si un client a peu de chances de voir plusieurs pages. Étant donné que le client n'émet pas de demande distincte pour le JS, cette stratégie charge la page plus rapidement - pour la première fois au moins, mais il existe un point d'équilibre où la mise en cache est meilleure. Vous pouvez inclure le JS par exemple via PHP.
Ici, le client n'a pas besoin d'un accès séparé au fichier JS, qui peut être masqué si vous le souhaitez. Mais n'importe qui peut toujours voir le code JS à l'intérieur du HTML.
D'autres stratégies pour minimiser les temps de chargement incluent
Minification JS qui réduit la taille du fichier JS que vous servez. Comme la minification ne se produit qu'une seule fois lors du déploiement du code, il s'agit d'une méthode très efficace pour économiser des octets. OTOH cela rend votre code plus difficile à comprendre pour les visiteurs intéressés.
Liée à la minification est la pratique de combiner tous vos fichiers JS dans un seul fichier. Cela réduit le nombre de demandes nécessaires.
Compression, qui ajoute une surcharge de calcul pour chaque demande sur le client et le serveur. Cependant, le temps passé (dé) compressé est généralement inférieur au temps passé à transmettre les données non compressées. La compression est généralement gérée de manière transparente par le logiciel serveur.
Ces techniques s'appliquent également à d'autres ressources comme les images.
- Les images peuvent être insérées en HTML ou CSS avec des URL de données. Cela n'est pratique que pour les petites images simples, car l'encodage base64 gonfle la taille. Cela peut toujours être plus rapide qu'une autre demande.
- Plusieurs petites images (icônes, boutons) peuvent être combinées en une seule image, puis extraites sous forme de sprites.
- Les images peuvent être réduites par le serveur à la taille dans laquelle elles sont réellement utilisées sur le site Web, ce qui économise de la bande passante. Comparez les images miniatures.
- Pour certains graphiques, les images textuelles comme SVG peuvent être beaucoup plus petites.
Si vous n'avez qu'une seule page, alors oui, il est préférable (du point de vue des performances) de tout servir dans un seul fichier ... des feuilles de style, du JavaScript et même des images (petites images alignées avec des URI de données). Cela élimine les demandes HTTP supplémentaires nécessaires pour récupérer des ressources externes qui sont relativement lentes.
Le fichier résultant doit être compressé avant de servir, ce qui réduira considérablement la taille de la réponse en texte intégral.
Vous devez toujours envisager d'avoir de grandes images externes à la page, car il y a des limites à la taille des URI de données et à la compatibilité du navigateur. (Par exemple, IE8 a une limite de 32 Ko, ce qui équivaut à une taille de fichier réelle d'environ 23 Ko en raison de la nature de l'encodage base64.)
Non. Au mieux, le code peut être obscurci afin de le "cacher" à l'observateur occasionnel, mais il n'offre aucune protection réelle.
la source
Le code JS côté client doit être vu par le navigateur (c'est-à-dire si la page doit utiliser JS directement) - cela signifie qu'il doit être téléchargé par le navigateur.
Un navigateur ne peut pas utiliser JS sur la page s'il ne peut pas le télécharger.
À cet égard, cela ne fait aucune différence si vous insérez le JS ou le placez dans un fichier, bien que la pratique courante consiste à utiliser un fichier JS (séparation des préoccupations pour un).
Si vous avez du code que vous ne souhaitez pas exposer au navigateur, vous devrez utiliser du code côté serveur (par exemple, node.js, php, perl, asp.net, jsp - il y a tellement d'options) et interagir avec lui depuis le navigateur - soit lors du chargement initial de la page, soit en utilisant AJAX .
la source
Eh bien, cela dépend de la quantité de code et de votre sérieux en tant que programmeur / ingénieur logiciel par rapport à un simple codeur. J'ai travaillé avec un tas de designers qui ont mis de courts extraits de code directement en HTML, et pendant que je grincais des dents - cela a réellement fonctionné.
Bien que ce ne soit pas quelque chose que je ferais moi-même, et si vous voulez connaître les meilleures pratiques de développement logiciel, je vous conseille fortement de tout mettre dans un
*.jsfichier externe et de le charger via des<script>balises.En ce qui concerne votre deuxième point, non, vous ne pouvez pas refuser à un utilisateur ou à un navigateur de voir votre code, il y a quelque chose appelé
obfuscationqui rendra votre code plus difficile à lire, mais les performances se dégraderont.la source
Il est préférable de créer un fichier externe pour votre code JS. Il est également préférable d'avoir un ou deux fichiers que vous servez au client. Mais, il est également préférable d'avoir votre code JS divisé en plusieurs fichiers pour des problèmes de maintenabilité. Pour ce faire, vous pouvez utiliser des préprocesseurs comme Gulp qui combineront vos différents fichiers JS en un seul fichier.
Servir moins de fichiers est meilleur car le client aura moins de requêtes HTTP à gérer.
Oui, évidemment, c'est plus rapide puisque vous ne faites qu'une seule demande pour le HTML, alors que vous feriez plusieurs demandes (au moins 2) avec votre code JS en tant qu'externe. C'est seulement si votre code JS n'est pas minifié des deux côtés, et cela ne prend pas en compte la difficulté de maintenir votre code s'il est tout dans une seule page HTML.
Non tu ne peux pas. Le code JS, comme le code CSS et le code HTML, est un contenu statique. Cela signifie qu'une fois qu'il est dans le navigateur, le client peut le télécharger entièrement et son contenu. Chaque fichier, image, script est ouvert pour être téléchargé. Mais , vous pouvez minimiser / uglifier votre code afin qu'il soit plus difficile pour un être humain de l'utiliser. Ce n'est qu'une conséquence de l'ugification, qui a d'abord été faite pour les performances.
la source
De nombreux avantages de séparer le contenu html et javascript dans des fichiers séparés:
la source