Der Server ist das, was hält,
wenn der Katalog wächst.

Une page catégorie qui met huit secondes alors qu'elle en mettait deux l'an dernier, c'est une base de données qui a grossi sans que ses index, le sommaire qui lui évite de tout relire, suivent. Ces trois symptômes se ressemblent vus de l'administration, tout paraît normal, et ils n'ont rien à voir entre eux. Le travail commence donc par un relevé, pas par une recommandation : quelles limites le serveur applique réellement, quelles tâches planifiées existent et lesquelles ont tourné cette semaine, quelles demandes lentes s'accumulent, ce que les sauvegardes contiennent vraiment.

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une hypothèse. Ensuite seulement vient le réglage : mémoire et temps d'exécution alignés sur les traitements les plus lourds, OPcache dimensionné (la réserve où le serveur garde le code déjà lu, pour ne pas le relire à chaque visite), tâches déclarées côté serveur plutôt que dépendantes d'une visite, index créés là où les demandes les réclament. Et une surveillance qui prévient avant le client : site injoignable, certificat expiré, espace disque, échec de sauvegarde.

Je travaille sur l'hébergement que vous avez, mutualisé o2switch, OVH, VPS (un serveur privé virtuel) ou dédié. Changer d'hébergeur est parfois la bonne réponse, mais c'est rarement la première : une boutique lente sur un mutualisé le reste souvent sur une machine plus grosse, parce que ce n'était pas la puissance qui manquait.