Laissez-moi d'abord vous expliquer pourquoi j'ai écrit cet article et pourquoi je suis aux prises avec ce petit problème. Tout d'abord, l'activation de la compression gzip des fichiers statiques est très utile pour améliorer la vitesse d'accès du site Web et réduit efficacement le temps nécessaire aux araignées pour explorer les pages statiques. En même temps, cela ne causera pas 200 0 aux araignées Baidu. comme activer la compression dynamique des fichiers. 64 problème d'exploration, donc d'une part, la vitesse rapide du site Web est propice à l'amélioration de l'expérience utilisateur. D'autre part, le blog de l'administrateur de Google a clairement indiqué cette année que la vitesse du site Web est l'un des facteurs de classement, ainsi que l'utilisation d'hébergeurs étrangers. pour créer des sites chinois Baidu L'optimisation et le temps insatisfaisant entraîneront moins d'exploration des pages internes par Baidu Spider. Guoping l'a également mentionné auparavant dans son article de blog : Comment la vitesse de chargement des pages Web affecte-t-elle l'effet SEO ? Dans une période de temps fixe, le temps total nécessaire à un robot pour explorer le site Web est fixe. Si la vitesse d'exploration augmente, le nombre de pages explorées sera plus important, et vice versa.
Bon, commençons par le texte principal. Dans la question 2 de l'article précédent « Résultats expérimentaux de l'exploration des pages statiques par Spider et déclenchement de la compression gzip », j'ai deviné comment la version compressée des pages statiques gzip est enregistrée sur le serveur. être confus pendant longtemps Après cela, j'ai découvert que la raison finale des différents résultats gzip renvoyés par les deux hôtes était la version iis plutôt que le paramètre du dossier de cache que je pensais être trop petit.
En fait, iis7 a une mise à jour plus importante que iis6 en compression statique. Dans IIS6, la compression statique est effectuée sur un thread différent, donc après avoir reçu une requête HTTP, la première envoyée au navigateur. La version HTML est décompressée et IIS6 démarrera. utiliser un thread différent pour compresser le fichier et stocker la version compressée dans le dossier cache du fichier compressé pendant une longue période. Dans le passé, c'est-à-dire sur le serveur IIS6, une fois la compression terminée, pour toute requête HTTP pour la version compressée du fichier statique, IIS6 appelait directement la version compressée depuis le dossier cache et la renvoyait au navigateur.
Mais dans IIS7, la compression est effectuée sur le thread principal, et afin d'économiser le coût de la compression, IIS7 n'enregistre pas les versions compressées à long terme de toutes les requêtes HTTP mais uniquement les fichiers statiques fréquemment consultés par les utilisateurs. la première fois que je l'ai visité, il n'a pas été compressé. La version compressée a été renvoyée lorsque je l'ai visité à nouveau dans un court laps de temps, mais la version non compressée a été renvoyée lorsque je l'ai visité après quelques minutes. Ici, nous pouvons comprendre qu'IIS7 n'enregistre pas réellement la version compressée dans le dossier cache, mais l'enregistre uniquement dans la mémoire du serveur, ou enregistre temporairement la version compressée dans le dossier cache et la supprime après un certain temps.
La méthode permettant à IIS7 de définir les fichiers fréquemment consultés et conformes aux normes de compression sont les deux propriétés suivantes dans system.webServer/serverRuntime, fréquentHitThreshold et fréquentHitTimePeriod. Si IIS reçoit l'accès à un fichier statique qui dépasse le seuil fréquentHitThreshold pendant la période fréquentHitTimePeriod, IIS7 compressera le fichier statique comme IIS6 et stockera la version compressée dans le dossier cache du fichier compressé pendant une longue période. Si une version mise en cache du fichier existe déjà dans le dossier cache lorsqu'un utilisateur accède à un fichier sur le site Web, IIS7 ne jugera plus la logique de fréquentHitThreshhold et renverra directement la version compressée au navigateur.
Ce paramètre est en effet très pénible, mais la réponse officielle de Microsoft est qu'il peut être utilisé pour améliorer les performances du serveur. . . Donc si vous voulez qu'IIS7 puisse compresser comme IIS6, il existe deux solutions, bien sûr, elles modifient toutes les deux les valeurs de fréquentHitThreshold et fréquentHitTimePeriod :
La première consiste à ajouter le contenu suivant à web.config, à ajuster fréquentHitThreshold à 1 et à ajuster fréquentHitTimePeriod à 10 minutes.
<système.serveurweb>
<serverRuntime activé=true
fréquentHitThreshold=1
fréquentHitTimePeriod=00:10:00/>
</system.webServer>
La deuxième méthode consiste à ouvrir %windir%/system32/inetsrv/appcmd.exe, puis à saisir la chaîne de commande suivante dans l'interface de ligne de commande, puis à appuyer sur Entrée.
définir la configuration -section:system.webServer/serverRuntime -frequentHitThreshold:1
Les responsables de Microsoft suggèrent qu'une approche moins radicale consiste non pas à réduire le fréquentHitThreshold mais à augmenter le fréquentHitTimePeriod, ce qui est plus modéré pour les performances du serveur. Ce que je veux mentionner ici, c'est que pour les amis qui ont un VPS, il est recommandé de le configurer manuellement. La possibilité pour les utilisateurs de l'hôte virtuel de le définir dépend du fournisseur de services. Malheureusement, je ne peux pas le modifier. Tout le monde, essayez-le