· 8 min de lecture

Beget CDN sur hébergement mutualisé : ce que ça donne vraiment

Cas global-cleaning-spb.ru : Lighthouse mobile 60 → 94, LCP 4,5 s → 1,9 s, CLS 0,377 → 0,001. Ce qu'a vraiment fait Beget CDN, et ce qui vient du code.

Quand on regarde un site sur hébergement mutualisé avec Lighthouse 60-70 et un LCP de 4 secondes, la première tentation - dire ‘il faut un VPS’. C’est cher, ça exige de l’administration système et ça se rentabilise rarement sur un site B2B à 10 000 visiteurs par mois.

Sur le projet global-cleaning-spb.ru j’ai pris un autre chemin : branché Beget CDN sur la statique et optimisé le code en parallèle. Lighthouse mobile est monté à 94/100, le LCP à 1,9 seconde, le CLS à 0,001. Sans déménagement. Je raconte ce que j’ai fait exactement, où le CDN a aidé et où non.

En bref

  • Lighthouse mobile : 60-70 → 94/100 (Performance), 100/100 (SEO)
  • LCP mobile : 4,5 s → 1,9 s
  • CLS : 0,377 → 0,001
  • TBT : 20 ms
  • TTFB : resté à ~1 seconde (le CDN ne sert pas le HTML)
  • Beget CDN distribue CSS, JS, polices, images. Le HTML est resté sur le shared.
  • Cloudflare ne convient pas à cause des blocages en Russie - pourquoi exactement.

Ce qu’il y avait ‘avant’

Le site tournait sur le mutualisé Beget sans CDN. Stack : PHP, sans CMS, code custom. Lighthouse mobile montrait ce tableau :

MétriqueValeur
Performance60-70/100
LCP mobile~4,5 secondes
CLS0,377
TTFB shared sans CDN~944 ms (plafond)

CLS 0,377, c’est la zone rouge - le classement est pénalisé dans Google comme dans Yandex depuis 2021. LCP 4,5 secondes, c’est quand l’utilisateur mobile en 4G voit un ‘écran blanc’ pendant presque tout le chargement. Lighthouse 60, c’est quand Google ne considère pas le site comme ‘de qualité du point de vue de l’expérience’.

Ce que j’ai fait

Deux axes parallèles : optimisation du code et CDN sur la statique.

Partie 1. Optimisation du code

C’est ce que Beget CDN ne fera pas à votre place. Le réseau de distribution ne réparera pas le CLS, ne retirera pas le JS inutilisé, ne cassera pas les dépendances du critical rendering path. D’abord le code, ensuite l’infrastructure.

CLS 0,377 → 0,002 en une journée. Analyse détaillée dans un article séparé, en bref :

  • Le logo a reçu des width et height explicites dans le HTML
  • .header-nav déplacé dans le critical CSS
  • Inter Fallback avec size-adjust: 107% et ascent-override: 90% sur base Arial - le ‘saut’ au chargement de la police éliminé

Après ces trois correctifs, le CLS a été divisé par 200 - de 0,377 à 0,002, puis à 0,001. Sans CDN, sans VPS, sans réécrire le front.

Self-host des polices. Inter Variable, font-display: swap. La police est sur mon propre hébergement, pas sur des serveurs tiers. J’ai retiré une dépendance externe qui pouvait bloquer le rendu.

WebP pour toutes les images. 192 liens dans 92 fichiers PHP, conversion en une journée. 24 PNG compressés de 71-97 %, 108 JPG - de 23-85 %. Dimensions dans le HTML, loading="lazy" pour tout ce qui est sous la ligne de flottaison, fetchpriority="high" pour l’image hero.

OPcache sur le shared. PHP reconstruisait les pages à chaque requête. J’ai branché OPcache - PHP sert désormais du bytecode en cache. Détails dans l’article séparé sur OPcache sur mutualisé.

Partie 2. Beget CDN sur la statique

Dans le panneau Beget, ça s’active d’une case à cocher. Après activation, le site reçoit un domaine CDN du type ikeyegdufakeg.begetcdn.cloud, et tout le contenu statique - CSS, JS, polices, images - passe par des serveurs edge en Russie.

J’ai ajouté le domaine CDN dans la Content-Security-Policy du site - pour que les navigateurs autorisent le chargement depuis là :

script-src 'self' 'unsafe-inline' 'unsafe-eval' https://ikeyegdufakeg.begetcdn.cloud
style-src 'self' 'unsafe-inline' https://ikeyegdufakeg.begetcdn.cloud
font-src 'self' https://ikeyegdufakeg.begetcdn.cloud
img-src 'self' data: https://ikeyegdufakeg.begetcdn.cloud

C’est tout. Aucune migration DNS, aucun déport du projet sur des serveurs tiers. Même hébergeur, domaine au même endroit, zéro risque réglementaire.

Ce que j’ai obtenu ‘après’

PageSpeed Insights du 1er juin 2026, Lighthouse 13.3.0 :

Mobile (émulation Moto G Power, 4G slow)

MétriqueAvantAprès
Performance60-7094/100
SEO-100/100
Accessibility-97
Best practices-96
FCP-1,9 s
LCP4,5 s1,9 s
TBT-20 ms
CLS0,3770,001
Speed Index-5,5 s

Desktop

MétriqueValeur
Performance92/100
LCP0,7 s
TBT20 ms
CLS0,085
FCP0,6 s

Total Blocking Time 20 ms - là c’est le JS pur de la page, pas le réseau de distribution. CLS 0,001 - c’est ‘rien ne bouge du tout’.

Ce que Beget CDN n’a PAS fait

C’est la partie importante de l’article, parce que les articles marketing sur les réseaux de distribution la sautent d’habitude.

Le TTFB n’a pas baissé. Mesure directe du 1er juin (5 requêtes espacées) :

MétriqueMobileDesktop
TTFB médiane~1,13 seconde~0,98 seconde
TLS handshake470-580 ms-
Total page time1,7-2,5 s1,6-1,7 s
HTTP200200
CacheX-Cache: HIT (Nginx)-

Le TTFB sur le mutualisé Beget bute sur trois choses : le handshake TLS, le cold start PHP et la bande passante du serveur shared. L’edge n’aide sur aucune des trois, parce que le HTML est servi par le serveur d’origine.

Si vous voyez des articles du genre ‘on a branché un CDN - le TTFB a été divisé par 5’, on y compare habituellement nginx + CDN avec Apache sans opcache. À matériel comparable, le réseau de distribution ne réduit pas le TTFB d’une page dynamique - il accélère tout ce qui vient après le premier octet.

Le Cache-Control n’est pas hérité du .htaccess. Si le .htaccess contient un mod_expires avec un cache d’un an pour la statique, ça n’arrivera pas sur l’edge. Par défaut, le cache est à max-age=300 (5 minutes). Pour des URL versionnées (avec hash dans le nom de fichier), c’est trop peu - il faut configurer via le panneau Beget ou vivre avec le défaut.

Géographie : Russie et CEI uniquement. Si 30 % de l’audience est en EU ou aux US, les serveurs edge en Russie ne les aideront pas. L’audience de global-cleaning-spb.ru est entièrement en Russie - ça marche. Pour un projet international, la solution ne convient pas.

À qui ça convient, à qui non

Ça convient :

  • Site B2B local en Russie
  • Hébergement mutualisé, pas envie de migrer sur un VPS
  • Lighthouse actuel 60-80, objectif 90+
  • Audience entièrement en Russie ou CEI
  • Budget limité (gratuit avec les tarifs payants Beget)

Ça ne convient pas :

  • Audience globale avec une part russe < 50 %
  • Besoin d’un TTFB < 200 ms (uniquement VPS + reverse proxy)
  • Protection DDoS niveau L7 (Beget n’est pas un WAF)
  • Edge-compute serverless (Workers, R2) - il faut Cloudflare ou Yandex Cloud

Ce que je ferais sur un nouveau projet

L’ordre est celui-ci :

  1. D’abord optimiser le code. Dimensions d’images dans le HTML, critical CSS, polices fallback avec size-adjust, OPcache, WebP. Sans budget, de ses propres mains.
  2. Ensuite brancher Beget CDN sur la statique (ou Yandex Cloud CDN, Selectel CDN si vous n’êtes pas chez Beget). Ça soulage le shared, décharge les processus PHP.
  3. Seulement après penser au VPS. Si après les deux étapes Lighthouse est coincé et le TTFB gêne encore - alors le déménagement. Sur mon cas, on n’en est pas arrivé là.

Lighthouse 94 mobile sur hébergement mutualisé, ce n’est pas de la ‘magie CDN’. C’est la somme de petits correctifs de code et le déchargement de la statique via le réseau de distribution gratuit de l’hébergeur.

Liens utiles

Envie du même résultat sur votre projet ? Je le prends en audit ponctuel ou je fais la configuration complète via le SEO à partir de zéro.

Questions fréquentes

Beget CDN est gratuit ou pas ?
Gratuit si vous avez un hébergement payant Beget. Il s'active d'une case à cocher dans le panneau et sert la statique depuis des serveurs edge en Russie. Côté trafic - gratuit jusqu'à une certaine limite, ensuite facturation journalière en roubles. Sur mon projet à audience B2B, le volume gratuit suffit largement, je n'ai jamais touché la limite.
Beget CDN accélère le TTFB ou pas ?
Non. Le TTFB, c'est le premier octet du HTML, rendu par le serveur d'origine. Sur le mutualisé Beget, le TTFB bute sur un plafond de ~1 seconde à cause du handshake TLS de 470-580 ms et du cold start PHP. Le réseau de distribution sert CSS, JS, polices, images - tout ce qui vient après le HTML. Si votre objectif est un TTFB < 200 ms, allez sur un VPS avec reverse proxy.
À quoi bon un CDN s'il n'accélère pas le TTFB ?
Il accélère tout sauf le premier octet - et ça pèse lourd dans Lighthouse. Sur global-cleaning-spb.ru, la statique (CSS, JS, polices, icônes) passe par Beget CDN, ce qui réduit le LCP et le Speed Index. En parallèle ça décharge le shared - les processus PHP ne servent plus la statique, seulement le HTML. Résultat au 1er juin 2026 : Lighthouse mobile 94 en 4G slow, LCP 1,9 s.
Et Cloudflare CDN, pas mieux ?
En Russie 2024-2026 - non. Cloudflare est bloqué via DPI chez les FAI, une partie des utilisateurs voit le site lent ou avec des échecs SSL. J'ai tout détaillé dans un [article séparé](/fr/blog/cloudflare-v-rf-pochemu-otkazalsya/). Pour une audience globale, Cloudflare garde du sens. Pour du B2B local russe - Beget CDN, Yandex Cloud CDN ou Selectel CDN.
Que faut-il absolument faire en plus du CDN ?
D'abord optimiser le code. Un CDN ne réparera pas un CLS de 0,377, ne réduira pas le Total Blocking Time, ne purgera pas le CSS inutilisé. Sur global-cleaning-spb.ru il y a eu : dimensions du logo explicites dans le HTML (width/height), header-nav dans le critical CSS, Inter Fallback avec size-adjust:107% / ascent-override:90%. Le CLS a été divisé par 200 grâce à ces trois correctifs de critical CSS - avant le branchement du CDN, pas après.
Quels sont les inconvénients de Beget CDN ?
Trois. Premier : Russie et CEI uniquement - si 30 % de l'audience est à l'étranger, les serveurs edge n'aident pas. Deuxième : le Cache-Control du .htaccess n'est pas hérité - il faut configurer via le panneau Beget ou vivre avec le max-age=300 par défaut. Troisième : la statique passe par un domaine CNAME (par exemple begetcdn.cloud), certains systèmes antifraude des régies publicitaires ne le comprennent pas - vérifiez sur des campagnes pilotes.
Et si je ne suis pas chez Beget ?
Yandex Cloud CDN ou Selectel CDN - mêmes serveurs edge en Russie, à partir de 0,7 RUB par 1 Go sortant. Branchement plus complexe (CNAME sur un domaine séparé, configuration manuelle de l'origine), mais indépendant de l'hébergeur. Pour la plupart des projets B2B, la différence dans Lighthouse sera minime.