Dans la Joomla 4 Performance Tuning - Partie I , j'ai expliqué pourquoi le réglage des performances de votre site est quelque chose que vous devriez faire pour des raisons à la fois philosophiques et pratiques, ainsi que par où commencer. Ce message était par nécessité un peu générique. Dans la deuxième partie de cette série, nous allons plonger dans certaines des choses de base que vous pouvez faire dans Joomla pour débloquer une quantité décente de performances.
Paramètres système de base
Lors de la création d'un site, nous sommes tellement absorbés par la conception et les fonctionnalités que nous oublions que certains paramètres système très basiques et assez simples peuvent avoir un impact considérable sur les performances de nos sites. Quelques commutateurs simples dans la configuration globale avant de livrer le site et quelques vérifications de serveur simples peuvent faire toute la différence dans le monde.
Mise en cache
La plupart du temps passé côté serveur d'un site est lié à la construction de la page qui sera affichée au visiteur. Joomla, contrairement à WordPress, dispose d'un système de mise en cache intégré. Je pense que les gens ne lui accordent pas assez de crédit parce qu'ils étaient habitués à l'expérience de mise en cache inférieure à Joomla 1.0 et 1.5. C'était il y a 10 ou 15 ans.
Accédez à la configuration globale de votre site et définissez la mise en cache sur "ON - Progressive Caching". L' mise en cache progressive option de est la meilleure implémentation de la mise en cache intégrée de Joomla, en s'assurant que la sortie de chaque extension utilisée pour construire votre page est mise en cache individuellement. Lorsqu'une demande arrive, la page est assemblée à partir de ces éléments de contenu mis en cache dans la mesure du possible. Cela peut même contribuer à atténuer certaines performances perdues à cause d'un modèle pré-construit et non optimisé. Cela contribuera certainement à rendre vos pages publiques non connectées plus rapides - exactement ce qui est le plus pertinent pour le classement de votre site dans les moteurs de recherche.
En ce qui concerne le back-end de mise en cache, la plupart des sites peuvent s'en sortir en utilisant la mise en cache de fichiers dont les performances sont similaires à celles de memcached ou Redis fonctionnant sur un hôte décent, commercial, partagé ou virtualisé - avec beaucoup moins d'utilisation de la mémoire, donc beaucoup moins cher à Cours. "Hérésie!" le plus techniquement d'esprit entre vous pleure. Je suis d'accord avec votre sentiment, dans une certaine mesure. Si vous avez un site vraiment volumineux ou extrêmement occupé, il est logique d'utiliser un serveur Memcached ou Redis dédié comme backend de mise en cache. Ce sera plus rapide. Il y a de fortes chances que si vous lisez ceci, vous n'avez pas, en fait, ce genre de site, et vous cherchez à accélérer un site beaucoup plus banal. Même mon propre site d'entreprise entre dans cette catégorie, malgré le fait que nous recevons du trafic de l'ordre de centaines de dizaines de milliers de visiteurs mensuels uniques. Cela devrait vous donner une idée de l'échelle du site qui bénéficierait de la mise en cache à l'aide d'un serveur de mise en cache dédié.
HTML compression
S'il y avait un concours pour l'option la plus négligée dans Joomla, Gzip Page Compression gagnerait haut la main. Si vous ne l'avez pas déjà fait, allez-y et activez-le.
Cette option garantit que le contenu HTML envoyé par votre site au navigateur est compressé à l'aide de l'algorithme GZip (également appelé "deflate"). Cela réduit considérablement la taille totale des données transférées au client. Le temps gagné dans le transfert de données a un impact significatif sur les performances de votre site.
Cela ne ralentit-il pas le site ? Non, pas vraiment. Les pages HTML générées par Joomla sont de l'ordre de quelques dizaines de kilo-octets. Il faut une fraction de milliseconde pour compresser à environ un tiers à la moitié de cette taille. Avec les vitesses de transfert typiques entre un hôte et vos visiteurs, cela se traduit par quelques millisecondes de temps gagné. Vous gagnez deux à trois ordres de grandeur de plus de temps que vous n'en perdez dans ce cas.
Compression JavaScript et CSS
De nombreux modèles et plugins tiers prétendent gagner du temps en compressant vos fichiers statiques (JavaScript et CSS) à la volée. Je recommande fortement que vous do notn'utilisez ce type de fonctionnalités. Bien que la compression des fichiers statiques économise du temps de transmission, vous vous retrouvez avec une perte nette de performances.
La raison de ce résultat contre-intuitif nécessite de parler de la façon dont les serveurs fournissent du contenu statique et dynamique. Un serveur Web correctement configuré met souvent en cache du contenu statique en mémoire. De plus, il utilise des fonctionnalités avancées du système d'exploitation telles que le mappage de la mémoire des fichiers . Ceux-ci se traduisent par une livraison très rapide du contenu statique.
Lorsque vous utilisez un script PHP pour compresser vos fichiers statiques, le serveur Web doit transmettre la requête à l'exécutable PHP. Dans le meilleur des cas (PHP FastCGI Process Manager alias PHP-FPM, avec un pool de processus suffisamment important et PHP OPcache activé), cela fait encore perdre du temps à faire la communication inter-processus et à réinitialiser l'état de l'analyseur PHP. Le script doit être confirmé comme inchangé, sa représentation binaire précompilée chargée et interprétée, exécutée par le binaire PHP, le fichier statique doit être ouvert, son contenu compressé et envoyé à Apache pour le livrer au client. Tout cela prend des dizaines de millisecondes. À moins que vous ne compressiez un fichier de plusieurs centaines de kilo-octets, le temps que vous perdez est bien plus important — d'un ou deux ordres de grandeur ! — au temps gagné par la livraison d'un fichier compressé plus petit. C'est donc une perte nette.
Je recommande fortement de le faire via votre serveur Web lui-même. Si vous utilisez Apache, vous pouvez ajouter les éléments suivants à votre fichier .htaccess :
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript image/svg+xml
</IfModule><IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_keep_workfiles No
mod_gzip_can_negotiate Yes
mod_gzip_add_header_count Yes
mod_gzip_send_vary Yes
mod_gzip_min_http 1000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 512000
mod_gzip_maximum_inmem_size 60000
mod_gzip_handle_methods GET
mod_gzip_item_include file \.(html?|txt|css|js|php|pl|xml|rb|py|svg|scgz)$
mod_gzip_item_include mime ^text/plain$
mod_gzip_item_include mime ^text/xml$
mod_gzip_item_include mime ^text/css$
mod_gzip_item_include mime ^application/xml$
mod_gzip_item_include mime ^application/xhtml+xml$
mod_gzip_item_include mime ^application/rss+xml$
mod_gzip_item_include mime ^application/javascript$
mod_gzip_item_include mime ^application/x-javascript$
mod_gzip_item_include mime ^image/svg+xml$
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_include handler ^server-info$
mod_gzip_item_include handler ^application/x-httpd-php
mod_gzip_item_exclude mime ^image/.*
</IfModule>
Votre serveur Web beaucoup compresse plus rapidement les fichiers multimédias statiques. Il peut conserver les fichiers compressés en mémoire cache pour une livraison plus rapide la prochaine fois.
Joomla 4 augmente également la mise en vous permettant de compresser vos fichiers statiques à l'avance avec GZip , en fournissant les fichiers pré-compressés au lieu de les faire compresser par votre serveur Web à la demande. Cela fonctionne comme ça. Disons que vous avez le fichier JavaScript media/com_example/js/something.min.js. Compressez-le avec GZip dans media/com_example/js/something.min.js.gz. Lorsqu'un navigateur demande le fichier media/com_example/js/something.min.jsle serveur web vérifiera son AcceptsEn-tête HTTP pour voir s'il prend en charge les ressources compressées GZip. Si c'est le cas, il fournira le media/com_example/js/something.min.js.gzfichier au lieu du fichier régulier, non compressé media/com_example/js/something.min.jsdéposer.
La condition préalable à cela est que vous renommez le htaccess.txtfichier livré avec Joomla à .htaccess. Sinon, si vous gérez votre propre fichier .htaccess, assurez-vous que le code suivant est inclus dans votre fichier :
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
Joomla 4 fournit les fichiers .gz pré-compressés pour tous ses fichiers JavaScript et CSS statiques dans sa distribution. L'activation de cette astuce .htaccess rendra votre site encore plus rapide avec un minimum d'effort. Génial, n'est-ce pas ?!
Mise en cache des médias statiques
Réduire la taille des médias statiques avec la compression est la moitié de la bataille et concerne principalement les visiteurs novices. Lorsque quelqu'un revient sur votre site, il est logique que son navigateur serve des médias statiques à partir du cache du navigateur, sans toucher du tout le réseau. Si vous utilisez Apache, vous pouvez utiliser le code suivant dans votre fichier .htaccess :
<IfModule mod_expires.c> # Enable expiration control ExpiresActive On # CSS and JS expiration: ExpiresByType text/css "now plus 1 year" ExpiresByType application/javascript "now plus 1 year" ExpiresByType application/x-javascript "now plus 1 year" # Image files expiration: 1 month after request ExpiresByType image/bmp "now plus 1 year" ExpiresByType image/gif "now plus 1 year" ExpiresByType image/jpeg "now plus 1 month" ExpiresByType image/jp2 "now plus 1 month" ExpiresByType image/pipeg "now plus 1 month" ExpiresByType image/png "now plus 1 month" ExpiresByType image/svg+xml "now plus 1 month" ExpiresByType image/tiff "now plus 1 month" ExpiresByType image/vnd.microsoft.icon "now plus 1 month" ExpiresByType image/x-icon "now plus 1 month" ExpiresByType image/ico "now plus 1 month" ExpiresByType image/icon "now plus 1 month" ExpiresByType image/webp "now plus 1 month" ExpiresByType text/ico "now plus 1 month" ExpiresByType application/ico "now plus 1 month" ExpiresByType image/vnd.wap.wbmp "now plus 1 month" ExpiresByType application/vnd.wap.wbxml "now plus 1 month" ExpiresByType application/smil "now plus 1 month" # Font files expiration: 1 week after request ExpiresByType application/vnd.ms-fontobject "now plus 1 week" ExpiresByType application/x-font-ttf "now plus 1 week" ExpiresByType application/x-font-opentype "now plus 1 week" ExpiresByType application/x-font-woff "now plus 1 week" ExpiresByType font/woff2 "now plus 1 week" ExpiresByType image/svg+xml "now plus 1 week" # Audio files expiration: 1 month after request ExpiresByType audio/ogg "now plus 1 month" ExpiresByType application/ogg "now plus 1 month" ExpiresByType audio/basic "now plus 1 month" ExpiresByType audio/mid "now plus 1 month" ExpiresByType audio/midi "now plus 1 month" ExpiresByType audio/mpeg "now plus 1 month" ExpiresByType audio/mp3 "now plus 1 month" ExpiresByType audio/x-aiff "now plus 1 month" ExpiresByType audio/x-mpegurl "now plus 1 month" ExpiresByType audio/x-pn-realaudio "now plus 1 month" ExpiresByType audio/x-wav "now plus 1 month" # Movie files expiration: 1 month after request ExpiresByType application/x-shockwave-flash "now plus 1 month" ExpiresByType x-world/x-vrml "now plus 1 month" ExpiresByType video/x-msvideo "now plus 1 month" ExpiresByType video/mpeg "now plus 1 month" ExpiresByType video/mp4 "now plus 1 month" ExpiresByType video/quicktime "now plus 1 month" ExpiresByType video/x-la-asf "now plus 1 month" ExpiresByType video/x-ms-asf "now plus 1 month" </IfModule>
Une question raisonnable est de savoir ce qui se passe si vous mettez à jour Joomla et/ou des extensions tierces. Les fichiers statiques — JavaScript, CSS, images, ... — changent dans le cadre de la mise à jour. Nous ne voulons pas que le navigateur utilise l'ancien fichier. Au mieux le site aura l'air bizarre, au pire il sera cassé pour le visiteur. C'est là qu'intervient la gestion des versions des médias avec des paramètres de requête. Si vous regardez le code source de votre site, vous verrez des lignes comme celle-ci :
<link href="/media/plg_system_webauthn/css/button.min.css?f15d039055248502c1a41bc99a31c0f3" rel="stylesheet">
Cette ?f15d039055248502c1a41bc99a31c0f3s'appelle une requête de versionnage de média. Les éléments après le point d'interrogation n'ont pas d'importance, tant qu'ils changent à chaque fois que le fichier statique change. Joomla - et les extensions tierces correctement écrites - le font automatiquement pour les fichiers CSS et JavaScript. Si vous incluez d'autres contenus statiques dans vos articles tels que des images, des vidéos, etc., n'oubliez pas d'ajouter une requête de version. Quelque chose d'aussi simple que ?20211205111300(un point d'interrogation suivi de l'année, du mois, du jour, de l'heure, des minutes et des secondes - l'heure à laquelle vous avez écrit cette requête) est plus que suffisant.
HTTPS et HSTS
Il existe une idée fausse commune selon laquelle HTTPS a quelque chose à voir avec la sécurisation de votre site, c'est cher, c'est lent et vous n'en avez pas vraiment besoin à moins que vous ne fassiez du commerce électronique ou quelque chose du genre. Une autre idée fausse est que cela ralentit votre site.
Ces mythes sont nés à la fin des années 1990. Il y a plus de deux décennies, ils sont manifestement faux.
HTTPS est à peu près obligatoire de nos jours. Si vous n'utilisez pas HTTPS, votre site apparaîtra avec un gros avertissement rouge indiquant à vos visiteurs qu'il n'est pas sécurisé, ce qui effraie les visiteurs. Il sera pénalisé par les moteurs de recherche. Vous devriez utiliser HTTPS ne serait-ce que pour résoudre ces deux problèmes. Vous n'avez même pas besoin de casser la tirelire. Les certificats TLS sont désormais gratuits grâce à Let's Encrypt . La plupart des panneaux de contrôle d'hébergement s'intègrent à Let's Encrypt, ce qui signifie que vous pouvez littéralement avoir votre problème de panneau de contrôle d'hébergement et installer un certificat TLS gratuit et le renouveler automatiquement. Il n'y a aucun entretien de votre part. HTTPS est également ultra-rapide puisque tout processeur moderne, sorti au cours des dix dernières années, dispose d'une accélération matérielle pour les opérations cryptographiques qu'il utilise.
Pendant que vous y êtes, n'oubliez pas de définir « Forcer HTTPS sur l'ensemble du site » dans votre configuration globale. Cela garantit que votre site Joomla sera toujours livré via HTTPS, ce qui rend les connexions plus sécurisées dans le processus. Une fois que vous avez fait cela et que vous avez confirmé que HTTPS fonctionne parfaitement avec votre site, ajoutez ce qui suit à votre .htaccess :
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS </IfModule>
Cela active une fonctionnalité appelée HSTS (HTTP Strict Transport Security) . En bref, il dit à votre navigateur de ne jamais essayer de se connecter à la version HTTP de votre site, peu importe ce que votre visiteur lui dit de faire. Étant donné que cela se produit du côté du navigateur, un visiteur qui tape votre nom de domaine dans la barre d'adresse sans le https://préfixe, ou clique sur un lien avec le http://préfixe, accédera toujours à la version HTTPS de votre site sans avoir à visiter d'abord la version HTTP simple et à être redirigé par Joomla. C'est beaucoup plus rapide, en particulier sur les connexions à haute latence telles que l'Internet mobile ou par satellite.
Une autre optimisation que vous pouvez faire est de soumettre votre site à la liste de préchargement HSTS . Bien que HSTS ne fonctionne qu'après la première visite de votre site, le fait d'avoir votre site dans la liste de préchargement HSTS signifie que le navigateur connaît votre site en utilisant HSTS avant la première fois que votre visiteur le visite. Par conséquent, le navigateur n'essaiera jamais de le charger via HTTP simple. Encore une fois, c'est un gain de temps pour les connexions à haute latence, faciles et gratuites. Qu'est-ce qu'il n'y a pas à aimer ?
Poussée du serveur HTTP/2
Dans le passé, lorsque je parlais de rendre Joomla plus rapide, je disais aux gens comment activer HTTP/2 Server Push pour rendre les sites plus rapides. Cependant, les développeurs de Google Chrome ont déjà proposé de supprimer sa prise en charge et ont déclaré qu'il ne serait de toute façon pas implémenté pour le protocole HTTP/3. Par conséquent, mon conseil actuel est de ne même pas s'en soucier.
