Optimisations Apache2 : les réglages indispensables pour un site web performant

TL;DRApache 2.4 peut servir un site très rapidement, à condition de quitter ses réglages hérités. Voici les optimisations que nous jugeons indispensables, chacune avec sa configuration commentée, sa méthode de vérification et ce que nous avons mesuré sur notre propre serveur.

📌 Pourquoi régler Apache à la main ?#

Apache 2.4 reste l'un des serveurs web les plus répandus, mais sa configuration par défaut vise la compatibilité, pas la vitesse. Selon la distribution et l'historique du serveur, vous pouvez hériter d'un PHP exécuté dans Apache, de compressions incomplètes, de fichiers .htaccess lus à chaque requête ou d'en-têtes de cache absents. Chacun de ces points se corrige en quelques lignes.

Cet article passe en revue les réglages qui comptent vraiment, dans l'ordre où nous les vérifions. Chaque bloc de configuration est commenté et s'appuie sur la documentation officielle d'Apache. Nous indiquons aussi ce que nous utilisons réellement sur le serveur qui héberge websource.fr (Apache 2.4.69 sous Debian 13, PHP-FPM, derrière Cloudflare), avec des relevés faits le 17 octobre 2026.

Bon à savoir. Avant chaque rechargement d'Apache, testez la syntaxe avec apache2ctl configtest. Si la commande ne répond pas « Syntax OK », ne rechargez pas : corrigez d'abord. Un reload sur une configuration invalide peut arrêter le serveur et couper tous les sites qu'il héberge.

# 1. Vérifier la syntaxe : doit afficher « Syntax OK »
sudo apache2ctl configtest
# 2. Seulement si c'est le cas, recharger sans couper les connexions en cours
sudo systemctl reload apache2

📌 1. MPM event et PHP-FPM au lieu de prefork et mod_php#

Le MPM (module multi-processus) décide comment Apache traite les connexions. Le modèle historique, prefork, consacre un processus complet à chaque connexion. Il est imposé par mod_php, qui charge PHP dans chaque processus Apache : même une image ou un fichier CSS est alors servi par un processus qui embarque tout PHP en mémoire.

Le MPM event utilise des threads. Sa particularité, décrite dans la documentation d'Apache : un thread d'écoute dédié garde les connexions en attente (keep-alive), si bien qu'une connexion inactive n'immobilise plus de thread de travail. PHP sort d'Apache et tourne dans PHP-FPM, un gestionnaire de processus séparé auquel Apache transmet les scripts via mod_proxy_fcgi.

Sur Debian ou Ubuntu, la bascule se fait ainsi (adaptez le numéro de version de PHP) :

# Installer PHP-FPM (remplacez 8.4 par votre version de PHP)
sudo apt install php8.4-fpm
# Désactiver mod_php et le MPM prefork
sudo a2dismod php8.4 mpm_prefork
# Activer le MPM event, le relais FastCGI et la configuration PHP-FPM fournie par Debian
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
# Toujours tester avant de redémarrer (un changement de MPM exige un restart)
sudo apache2ctl configtest && sudo systemctl restart apache2

La configuration activée par a2enconf contient l'essentiel : elle envoie tous les fichiers PHP au socket de PHP-FPM.

<FilesMatch "\.ph(?:ar|p|tml)$">
    # Chaque script PHP est transmis à PHP-FPM par un socket Unix
    SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost"
</FilesMatch>

Vérifiez le résultat avec apache2ctl -V : la ligne « Server MPM » doit indiquer event. C'est le cas sur notre serveur, où chaque site dispose en plus de son propre pool PHP-FPM, sous son propre utilisateur système. Ce cloisonnement limite les dégâts si un site est compromis et permet de régler la mémoire site par site.

📌 2. Dimensionner MaxRequestWorkers et ThreadsPerChild#

Avec event, trois directives fixent la capacité d'Apache. ThreadsPerChild est le nombre de threads par processus, ServerLimit le nombre maximal de processus, et MaxRequestWorkers le nombre total de requêtes traitées simultanément. La documentation impose que MaxRequestWorkers ne dépasse pas ServerLimit × ThreadsPerChild et soit un multiple de ThreadsPerChild.

La règle d'or, rappelée par le guide de performance d'Apache : un serveur web ne doit jamais utiliser sa mémoire d'échange (swap). Le calcul se fait donc à partir de la mémoire, et, avec PHP-FPM, c'est le pool PHP qui consomme l'essentiel. La méthode :

1. Mesurez la mémoire moyenne d'un processus PHP-FPM en charge normale, par exemple avec ps -C php-fpm8.4 -o rss=. Ce chiffre surestime un peu la réalité, car il compte la mémoire partagée (OPcache) dans chaque processus.
2. Retirez de la mémoire totale celle du système, de la base de données et d'Apache lui-même.
3. Divisez le reste par la taille d'un processus PHP : vous obtenez pm.max_children.
4. Réglez MaxRequestWorkers au-dessus de ce nombre, car Apache sert aussi les fichiers statiques sans solliciter PHP. Un thread coûte bien moins cher qu'un processus PHP.

Exemple de calcul (valeurs illustratives) : sur une machine de 8 Go, en réservant 1 Go au système et 2 Go à MariaDB, il reste environ 5 Go. Avec des processus PHP d'environ 100 Mo, cela donne une cinquantaine de processus PHP simultanés au maximum. Côté Apache, les valeurs par défaut (400 requêtes simultanées) suffisent alors largement.

<IfModule mpm_event_module>
    StartServers             4      # processus lancés au démarrage
    ServerLimit             16      # plafond de processus
    ThreadsPerChild         25      # threads par processus
    ThreadLimit             64      # ne pas dépasser sans raison
    MaxRequestWorkers      400      # <= ServerLimit x ThreadsPerChild, multiple de 25
    MinSpareThreads         75      # threads libres gardés en réserve
    MaxSpareThreads        250
    MaxConnectionsPerChild 20000    # recycle un processus après 20 000 connexions (fuites mémoire)
</IfModule>

; /etc/php/8.4/fpm/pool.d/monsite.conf : pool PHP-FPM dédié à un site
pm = dynamic
pm.max_children = 50        ; mémoire disponible / mémoire d'un processus PHP
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 1000      ; recycle chaque processus après 1 000 requêtes

Sur notre serveur, Apache tourne avec exactement ces valeurs pour le MPM. Le relevé de mod_status du 17 octobre 2026 à 15 h 32 UTC donne une moyenne de 16 requêtes par seconde depuis le dernier démarrage, et 9 threads occupés sur 125 disponibles à cet instant : la capacité d'Apache n'est pas le facteur limitant. Les processus Apache occupaient environ 43 Mo chacun, les processus PHP-FPM de websource.fr environ 107 Mo (mémoire partagée comprise). C'est bien côté PHP que se joue le dimensionnement.

# Observer la charge réelle (mod_status, accès limité à la machine elle-même)
curl -s "http://127.0.0.1/server-status?auto" | grep -E 'BusyWorkers|IdleWorkers|ReqPerSec'

📌 3. Activer HTTP/2#

HTTP/2 fait passer toutes les ressources d'une page dans une seule connexion, en parallèle, et compresse les en-têtes. Avec HTTP/1.1, le navigateur doit ouvrir plusieurs connexions et chacune repasse par la négociation TLS. Apache le prend en charge avec mod_http2 depuis la version 2.4.17. En pratique, HTTP/2 n'est utilisé par les navigateurs qu'en HTTPS.

# sudo a2enmod http2
<IfModule http2_module>
    # h2 = HTTP/2 sur TLS, http/1.1 en repli pour les vieux clients
    Protocols h2 http/1.1
    # Le push serveur est activé par défaut mais Chrome l'a abandonné : on le coupe
    H2Push off
</IfModule>

La directive Protocols peut être placée globalement ou dans chaque hôte virtuel. Vérifiez la négociation avec curl -s -o /dev/null -w '%{http_version}\n' https://votre-site.fr/ : la réponse doit être 2. C'est le cas sur notre serveur, où la connexion se négocie en TLS 1.3.

📌 4. Compresser avec Brotli, et gzip en repli#

La compression divise le poids du HTML, du CSS et du JavaScript. Apache propose deux modules : mod_deflate (gzip, universel) et mod_brotli (Brotli, disponible depuis Apache 2.4.26, plus efficace sur le texte). Les images JPEG, PNG, WebP ou AVIF sont déjà compressées : inutile de les recompresser.

# sudo a2enmod brotli deflate
<IfModule mod_brotli.c>
    # Qualité 0 à 11 ; 5 (défaut) est un bon compromis vitesse/gain à la volée
    BrotliCompressionQuality 5
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/xml \
        application/javascript application/json application/xml image/svg+xml
</IfModule>
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml \
        application/javascript application/json application/xml image/svg+xml
</IfModule>
# Indiquer aux caches que la réponse varie selon la compression acceptée
Header merge Vary "Accept-Encoding"

Voici ce que nous avons mesuré le 17 octobre 2026 sur notre page d'accueil et notre feuille de style principale, directement sur le serveur, en faisant varier l'en-tête Accept-Encoding envoyé par curl :

La compression divise le poids par cinq à sept, et Brotli fait encore gagner 12 à 15 % par rapport à gzip.

Ce relevé nous a aussi appris quelque chose. Quand le client annonce qu'il accepte les deux formats, comme le fait tout navigateur récent, notre serveur répond en gzip, pas en Brotli : les deux filtres sont déclarés à des endroits différents de la configuration (globalement et dans l'hôte virtuel), et c'est gzip qui passe en premier. Brotli ne sert donc qu'aux rares clients qui n'acceptent que lui. Vérifiez votre propre serveur avec la commande ci-dessous, en envoyant l'en-tête d'un vrai navigateur.

# Quelle compression le serveur choisit-il pour un navigateur récent ?
curl -s -o /dev/null -D - -H 'Accept-Encoding: gzip, deflate, br, zstd' https://votre-site.fr/ | grep -i content-encoding
# Taille transférée selon le format accepté
for enc in identity gzip br; do
  curl -s -o /dev/null -w "$enc : %{size_download} octets\n" -H "Accept-Encoding: $enc" https://votre-site.fr/
done

Une piste pour donner la priorité à Brotli est de déclarer les deux filtres dans une seule directive, enchaînés dans l'ordre voulu, et de retirer les déclarations en double. Cette variante n'est pas décrite telle quelle dans la documentation d'Apache : validez-la avec apache2ctl configtest, puis avec la commande curl ci-dessus, avant de la garder.

# Un seul endroit : Brotli d'abord ; si le client ne l'accepte pas, gzip prend le relais
AddOutputFilterByType BROTLI_COMPRESS;DEFLATE text/html text/plain text/css \
    application/javascript application/json application/xml image/svg+xml

⚡ 5. Cache navigateur : mod_expires, mod_headers et immutable#

Un fichier que le navigateur garde en cache n'est plus redemandé du tout. La règle sûre : un cache très long pour les fichiers dont le nom change à chaque modification (fichiers « versionnés » comme main-v5WUbqx.css, produits par la plupart des outils de build), et aucun cache partagé pour les pages HTML, qui changent sans changer d'adresse.

# sudo a2enmod expires headers
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/avif             "access plus 1 year"
    ExpiresByType image/webp             "access plus 1 year"
    ExpiresByType image/svg+xml          "access plus 1 year"
    ExpiresByType font/woff2             "access plus 1 year"
    ExpiresByType text/css               "access plus 1 year"
    ExpiresByType text/javascript        "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
    # Fichiers versionnés : un an, et « immutable » évite toute revalidation au rechargement
    <FilesMatch "\.(css|js|avif|webp|png|jpe?g|svg|woff2)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
    # Pages HTML : le navigateur doit revalider à chaque visite
    <FilesMatch "\.(html?|php)$">
        Header set Cache-Control "private, max-age=0, must-revalidate"
    </FilesMatch>
</IfModule>

Attention : immutable sur un fichier dont le nom ne change pas (un style.css modifié sur place) bloquerait vos visiteurs sur l'ancienne version pendant un an. Réservez-le aux fichiers versionnés. Sur notre site, la feuille de style principale part bien avec Cache-Control: public, max-age=31536000, immutable (relevé du 17 octobre 2026).

📌 6. KeepAlive : réutiliser les connexions#

Le keep-alive permet d'envoyer plusieurs requêtes dans la même connexion, sans refaire la poignée de main TCP et TLS. Il doit rester activé. Avec prefork, un délai d'attente long immobilisait un processus entier par visiteur inactif ; avec event, c'est le thread d'écoute qui garde ces connexions, ce qui rend le réglage beaucoup moins sensible. Un délai court reste raisonnable.

KeepAlive On
# Requêtes autorisées par connexion (défaut 100)
MaxKeepAliveRequests 200
# Secondes d'attente d'une nouvelle requête avant fermeture (défaut 5)
KeepAliveTimeout 2

Ce sont les valeurs de notre hôte virtuel. Pour les connexions HTTP/2, le délai d'inactivité se règle séparément avec la directive H2KeepAliveTimeout de mod_http2.

⚡ 7. AllowOverride None : le coût caché des .htaccess#

Quand AllowOverride autorise les fichiers .htaccess, Apache cherche un tel fichier dans chaque dossier du chemin demandé, à chaque requête. Le guide de performance d'Apache est explicite : pour les meilleures performances, utilisez AllowOverride None partout, et placez les règles directement dans la configuration de l'hôte virtuel, où elles sont lues une seule fois au démarrage.

<Directory /var/www/monsite/public>
    # Aucun .htaccess n'est recherché ni lu
    AllowOverride None
    Require all granted
    # Les règles de l'ancien .htaccess sont recopiées ici, par exemple pour un front controller :
    FallbackResource /index.php
</Directory>

Ce réglage n'est pas toujours possible. Un CMS comme WordPress ou PrestaShop réécrit lui-même son .htaccess (voir notre article .htaccess PrestaShop : c'est quoi et à quoi ça sert ?), et un hébergement mutualisé doit laisser ses clients le modifier. C'est aussi notre cas pour websource.fr : nous gardons AllowOverride All parce que des règles de redirection sont maintenues dans le .htaccess du site. Le compromis consiste à n'autoriser les .htaccess que dans le dossier public du site, jamais à la racine du système de fichiers (Debian y met AllowOverride None par défaut).

📌 8. Désactiver les modules inutiles#

Chaque module chargé occupe de la mémoire dans chaque processus et élargit la surface d'attaque. Listez-les avec apache2ctl -M (44 modules sur notre serveur, dont plusieurs pour le relais vers des services internes), puis retirez ce que vous n'utilisez pas.

# Lister les modules chargés
apache2ctl -M
# Exemples de modules souvent inutiles sur un site moderne (à vérifier au cas par cas)
sudo a2dismod autoindex   # listes de fichiers automatiques
sudo a2dismod cgi         # scripts CGI
sudo a2dismod status      # si vous ne surveillez pas /server-status
sudo apache2ctl configtest && sudo systemctl restart apache2

Ne désactivez rien à l'aveugle : un module retiré alors qu'une directive l'utilise sans garde <IfModule> fera échouer le test de syntaxe. C'est justement le rôle de configtest.

📌 9. HostnameLookups Off et des journaux maîtrisés#

Avec HostnameLookups On, Apache fait une résolution DNS inverse de chaque visiteur avant de finir la requête, ce qui ajoute de la latence à chaque appel. La valeur par défaut est Off : vérifiez simplement qu'aucune configuration héritée ne la réactive.

# Pas de résolution DNS des visiteurs (les adresses IP suffisent dans les journaux)
HostnameLookups Off
# Niveau de journal d'erreurs : warn en production, debug seulement pour un diagnostic
LogLevel warn
# Option : ne pas journaliser les accès aux fichiers statiques
SetEnvIf Request_URI "\.(css|js|avif|webp|png|jpe?g|svg|woff2|ico)$" statique
CustomLog ${APACHE_LOG_DIR}/monsite_access.log combined env=!statique

Les journaux d'accès restent précieux pour le diagnostic et la sécurité : ne les supprimez pas, allégez-les. Assurez-vous aussi que logrotate les fait tourner, sans quoi un disque plein finira par arrêter le serveur.

⚡ 10. TLS : cache de sessions, tickets et agrafage OCSP#

La négociation TLS coûte un aller-retour réseau et du calcul. Trois réglages la rendent plus légère et plus sûre : autoriser seulement TLS 1.2 et 1.3, garder en mémoire les sessions pour les reprises, et désactiver les session tickets, comme le recommande le générateur de configuration de Mozilla pour Apache (avec Apache, la clé de chiffrement de ces tickets n'est pas renouvelée tant que le serveur ne redémarre pas, ce qui affaiblit la confidentialité persistante).

# Protocoles : TLS 1.2 et 1.3 uniquement
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
# Cache des sessions TLS en mémoire partagée (mod_socache_shmcb), pour les reprises de session
SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
SSLSessionCacheTimeout 300
# Tickets de session désactivés (recommandation Mozilla pour Apache)
SSLSessionTickets off

L'agrafage OCSP (SSLUseStapling) permettait au serveur de joindre à la poignée de main la preuve que son certificat n'est pas révoqué, évitant au navigateur une requête vers l'autorité de certification. Il exige un SSLStaplingCache déclaré hors des hôtes virtuels. Mais Let's Encrypt a mis fin à OCSP en 2025 : ses nouveaux certificats ne contiennent plus d'adresse OCSP. Nous l'avons vérifié sur le nôtre le 17 octobre 2026 avec openssl x509 -noout -text : aucune ligne OCSP. Avec un certificat Let's Encrypt, l'agrafage n'a donc plus d'objet. Il reste utile avec une autorité qui publie encore un répondeur OCSP.

# Seulement si votre autorité de certification fournit encore OCSP
# (à placer HORS des <VirtualHost>)
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/ssl_stapling(32768)
# puis dans le <VirtualHost *:443>
SSLUseStapling on

📌 11. Le cas d'un CDN en frontal#

Quand un CDN (Cloudflare, par exemple) se place devant Apache, une partie du travail change de main : la connexion du visiteur, le protocole (HTTP/2, voire HTTP/3) et la compression vers le navigateur sont gérés par le CDN, et les fichiers statiques sont servis depuis son cache. Apache doit alors surtout bien faire trois choses.

• Envoyer des en-têtes de cache justes. Le CDN s'appuie sur votre Cache-Control. Notre feuille de style revient de Cloudflare avec le statut cf-cache-status: HIT (servie depuis le cache), notre page d'accueil avec DYNAMIC (toujours demandée au serveur), ce qui est voulu pour du HTML.
• Récupérer la vraie adresse IP des visiteurs. Sans réglage, vos journaux et vos protections contre les abus ne voient que les adresses du CDN. Le module mod_remoteip corrige cela, à condition de ne faire confiance qu'aux plages d'adresses publiées par le CDN.
• Bien comprendre la compression. Cloudflare demande le contenu à l'origine en Brotli ou gzip. Si la réponse porte Cache-Control: no-transform, il ne modifie pas la compression. C'est notre cas : notre HTML arrive donc chez les visiteurs en gzip, tel que notre serveur l'a produit, d'où l'intérêt de corriger la priorité de Brotli vue plus haut.

# sudo a2enmod remoteip
# Utiliser l'en-tête du CDN comme adresse du visiteur...
RemoteIPHeader CF-Connecting-IP
# ...mais uniquement quand la requête vient réellement du CDN (liste publiée par Cloudflare, à tenir à jour)
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
# (une ligne par plage IPv4 et IPv6 publiée)

Un CDN ne rend pas plus rapide une page qu'il ne met pas en cache. Le 17 octobre 2026 vers 15 h 30 UTC, médiane de dix requêtes lancées depuis le serveur lui-même : 28 ms pour un fichier statique demandé directement à Apache contre 51 ms à travers Cloudflare, et 145 ms contre 258 ms pour la page d'accueil, générée à chaque visite. Ces valeurs varient avec la charge du serveur au moment de la mesure ; l'écart, lui, est le passage par le proxy. Pour aller plus loin sur ce sujet, lisez notre article TTFB : mesurer et réduire le Time To First Byte.

📌 Récapitulatif des réglages#

Une fois ces réglages en place, mesurez l'effet sur vos pages réelles : notre guide PageSpeed Insights : comprendre et améliorer votre score explique comment lire les résultats, et Mon site est lent : le diagnostic en 5 étapes aide à trouver la vraie cause d'une lenteur, qui est souvent l'application plutôt que le serveur web.

📌 Se faire accompagner#

Websource héberge un grand nombre de sites sur des serveurs Apache configurés de cette façon : MPM event, un pool PHP-FPM par site, HTTP/2, compression et en-têtes de cache réglés, certificats HTTPS automatiques. Nos offres d'hébergement web démarrent dès 4,99 € HT/mois, et nous accompagnons nos clients dès la commande, migration comprise selon l'offre. Si vous gérez votre propre serveur, nous pouvons aussi en assurer l'infogérance : parlons de votre projet.

❓ Questions fréquentes#

📌 Quel MPM choisir pour Apache 2.4 ?#

Le MPM event, associé à PHP-FPM via mod_proxy_fcgi. Prefork n'a de sens que si vous dépendez encore de mod_php ou d'un module qui n'est pas compatible avec les threads.

📌 Comment savoir si Brotli fonctionne sur mon site ?#

Envoyez l'en-tête d'un navigateur récent avec curl (Accept-Encoding: gzip, deflate, br, zstd) et regardez l'en-tête content-encoding de la réponse. S'il indique gzip alors que mod_brotli est actif, l'ordre des filtres est à revoir.

📌 Faut-il supprimer les fichiers .htaccess ?#

Pour la performance, oui : AllowOverride None et règles dans l'hôte virtuel. Mais un CMS qui gère son propre .htaccess ou un hébergement mutualisé impose souvent de les garder ; limitez-les alors au dossier public du site.

📌 Faut-il activer l'agrafage OCSP ?#

Seulement si votre autorité de certification publie encore un répondeur OCSP. Les certificats Let's Encrypt n'en contiennent plus depuis 2025, l'agrafage est donc sans objet avec eux.

📌 Un CDN rend-il ces réglages inutiles ?#

Non. Le CDN s'appuie sur les en-têtes de cache envoyés par Apache, et toute page qu'il ne met pas en cache reste produite par votre serveur, avec le temps de passage par le proxy en plus.

Article publié le 22/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.