WordPress Heartbeat Control comment mettre en place le plus raisonnable (performance et fonctionnalité en même temps)

Beaucoup de gens le demandent".Contrôle du rythme cardiaque de WordPress Comment le mettre en place pour qu'il ait le plus de sens possible" pour résoudre un problème :Backend/Editeur/Frontend Déclenchement continu admin-ajax.php l'interrogation, qui entraîne un taux élevé d'utilisation de l'unité centrale, un retard en arrière-plan et une consommation des ressources de l'hôte.L'API Heartbeat a été conçue avec de bonnes intentions, mais avec un hébergement partagé, des serveurs bas de gamme et plusieurs personnes qui ouvrent des onglets en arrière-plan en même temps, elle peut facilement devenir ".Facteurs de stress invisibles"L'API Heartbeat est transmise par l'intermédiaire de l'API /wp-admin/admin-ajax.php Les demandes sont lancées périodiquement et les onglets continuent à fonctionner même s'ils sont ouverts et ne bougent pas, ce qui peut entraîner une charge élevée.

Tout d'abord, soyons clairs : qu'est-ce que l'API Heartbeat et pourquoi ralentit-elle le site ?

1) Rythme cardiaque Que faire ?

API Heartbeat est une fonction intégrée à WordPressMécanisme d'interrogation temporisée côté navigateurLa première consiste à permettre au backend ou au frontend d'interagir en "temps quasi réel", par exemple :

• Sauvegarde automatique de l'éditeur (autosave)
• Verrouillage éditorial des articles (verrouillage des messages pour éviter les écrasements multiples)
• Notifications en temps réel, gestion des files d'attente, rafraîchissement de l'état de certains plugins en arrière-plan

Ses caractéristiques sont les suivantes :Vous gardez la page ouverte, elle continue d'envoyer des requêtes..

2) Pourquoi il s'agit souvent d'un goulot d'étranglement au niveau des performances

Le cœur bat la chamade. admin-ajax.phpQuand :

• Plusieurs onglets ouverts en arrière-plan
• Plusieurs rédacteurs en ligne en même temps
• Le site comporte de nombreux plug-ins, et chaque traitement AJAX est très lourd.
  Et voilà.Empilement massif de POST/requêtesCela se traduit par une utilisation accrue de l'unité centrale et des arrière-plans plus lents.

II. l'organisation la plus logique : des contrôles séparés par "zone" (clé)

Un outil de contrôle Heartbeat fiable (Heartbeat Controller / Heartbeat Control-like plugin) vous permet généralement desous-régionalMettre en place trois blocs :

• Tableau de bord de l'administrateur
• Éditeur de pages (Post/Page Editor)
• Frontend

C'est le cœur de la "rationalisation" :Ne pas tout interdire de manière généraleAu lieu de cela, c'estMaintenez-le là où il est nécessaire, ralentissez-le ou fermez-le là où il n'est pas nécessaire.WP Rocket précise également que le fait de le désactiver complètement peut affecter les fonctionnalités qui s'appuient sur Heartbeat.

III. 80% site commun "configuration la plus recommandée" (pas facile à renverser)

Voici une configuration qui va dans ce sens :Réduction maximale des demandes tout en conservant les principales fonctionnalités de l'éditeur (sauvegarde automatique/verrouillage).

Configuration recommandée (version générique)

1. Tableau de bord: :Réduire / Modifier jusqu'à 120s ou directement Désactiver

• Pour la plupart des sites, les tableaux de bord n'ont pas besoin d'être "rafraîchis toutes les minutes en temps réel".
• C'est là que le ralentissement/la désactivation est généralement le plus gratifiant et le moins risqué.

2. Rédacteur en chef: :Modifier jusqu'à 60s(30 à 60 secondes pour une collaboration fréquente entre plusieurs personnes ; 60 à 120 secondes pour un poste unique)

• La désactivation pure et simple n'est pas recommandée : elle affecte la sauvegarde automatique, le verrouillage de l'édition, etc.
• Pour votre site d'articles ou de contenu, 60 secondes suffisent généralement pour une bonne communication.

3. Frontend: dans la plupart des cas, directement Désactiver

• Frontend Heartbeat n'est souvent pas une nécessité, sauf si vous avez besoin d'un chat en temps réel, d'un inventaire/enchère en temps réel, de notifications en temps réel, etc.
• De nombreux tutoriels/conseils d'hébergement préconisent également la désactivation du frontend pour réduire la charge (à l'exception des cas où le frontend nécessite une fonctionnalité dynamique).

Si vous utilisez WP Rocket : son option "Réduire l'activité" changera la fréquence deToutes les 1 minutestomber àToutes les 2 minutesest une option de compromis relativement sûre.

IV. l'adaptation à votre type de site (la clé pour être plus "sensible")

Scénario A : Site à contenu unique / Site de présentation de l'entreprise (le plus courant)

• Tableau de bord : désactivé ou 120s
• Éditeur : 60-120s
• Frontend : Désactiver
  raison d'êtreLes éditeurs sont rarement saisis par plus d'une personne à la fois, et vous n'avez pratiquement jamais besoin d'une actualisation en temps réel en arrière-plan.

Scénario B : Station multimédia multi-éditeurs / Collaboration fréquente

• Tableau de bord : 120s
• Éditeur : 30-60s (30-60 est plus recommandé, ne l'étirez pas trop longtemps)
• Frontend : Désactiver
  raison d'êtreLe verrouillage de l'édition et la sauvegarde automatique sont plus importants, il ne faut pas sous-fréquenter l'éditeur.

Scénario C : Le backend du centre commercial WooCommerce est très sollicité (beaucoup de commandes, d'inventaires et d'opérations de backend).

• Tableau de bord : 120 secondes (il n'est pas recommandé de tout désactiver, il faut d'abord ralentir et observer)
• Rédacteur en chef (s'il blogue moins) : 60-120s
• Frontend : Désactiver (sauf si le frontend a une forte composante temps réel)
  raison d'êtreIl se peut qu'il y ait un plugin en arrière-plan qui s'appuie sur Heartbeat pour rafraîchir l'état, il est donc plus sûr de le "ralentir" plutôt que de le "désactiver" complètement.

Scénario D : Adhésion/Forum/Cours en ligne (avec notifications en temps réel/chat à l'accueil)

• Tableau de bord : 120s
• Éditeur : 60s
• Frontend : ne pas désactiver, passer à 60-120s
  raison d'êtreLa fonctionnalité en temps réel du frontend peut s'appuyer sur Heartbeat, et un arrêt complet se traduira par des "notifications non mises à jour/état non actualisé".

V. Comment installer les plug-ins (étapes d'atterrissage)

Les noms des différentes interfaces de plugin varient légèrement, mais la logique est fondamentalement la même : pour chaque région, sélectionnez l'option Autoriser / Désactiver / Modifier.

Exemple d'un plugin de contrôle Heartbeat courant (chemin similaire dans les instructions de VeeroTech) :

• Accès aux coulisses :Paramètres > Paramètres de contrôle des battements de cœur
• Sélectionnez respectivement Dashboard / Post Editor / Frontend :
  • Autoriser (par défaut)
  • Désactiver
  • Modifier

Si vous utilisez WP Rocket : dans ses paramètres Heartbeat, vous pouvez choisir Reduce/Disable/Do not limit (Réduire/Désactiver/Non limiter), et souligner que "la désactivation complète peut affecter la fonctionnalité".

Sixièmement, la modification doit être effectuée après la liste de contrôle (afin d'éviter de "sembler accélérer, mais en fait enterrer").

1) Relatif à l'éditeur

• Nouvel article, séjour de 2 à 3 minutes : est-il toujours sauvegardé automatiquement ?
• Multi-open two browsers to log in the same account to edit the same article : is the locking prompt normal ?
• L'éditeur est-il bloqué ou la sauvegarde échoue-t-elle ?

2) Validation des performances (vous voulez voir "moins de demandes")

• Outils de développement du navigateur ouvert (réseau) Filtrage admin-ajax.php peut-être rythme cardiaque
• Comparer avant et après la modification : la fréquence des demandes est-elle réduite de manière significative ?
• Côté serveur pour voir si l'unité centrale et les charges diminuent (en particulier dans le cas d'un hébergement partagé).

VII. les idées fausses les plus courantes (où beaucoup de gens tombent)

Idée reçue 1 : "Désactivation directe sur l'ensemble du site".

Le fait de tout désactiver entraîne l'abandon des demandes, maisPeut interrompre la sauvegarde automatique, le verrouillage de l'édition et certaines fonctions de rafraîchissement en arrière-plan dépendant de plugins..WP Rocket Il prévient aussi explicitement que "la désactivation complète peut affecter la fonctionnalité".

Mythe 2 : Ne s'intéresser qu'à la vitesse de l'interface, ignorer le décalage en arrière-plan

Heartbeat a tendance à "torturer" principalement le backend et l'éditeur ; vous devriez vous concentrer sur cela :

• Ralentissement/désactivation du tableau de bord
• Rédacteur en chef Décélération conservatrice (ne les coupez pas tous)

Idée reçue n° 3 : s'attendre à ce que l'expérience d'édition soit normale lorsque la fréquence est réglée à un niveau trop bas (par exemple 300s+).

Un éditeur trop peu fréquent peut rendre les sauvegardes automatiques et les blocages lents, et les sites collaboratifs sont particulièrement visibles.

VIII. vous donner la "réponse finale" : quelle est la valeur par défaut la plus raisonnable ?

Si vous me demandez, sans connaître le type de votre site, de vous donner uneLe plus sûr et le moins piétinéJ'opterais pour les "valeurs par défaut raisonnables" :

• Tableau de bord : désactivé (ou 120s)
• Rédacteur en chef : 60s
• Frontend : Désactiver
• Si vous utilisez WP Rocket : Préférences Réduire l'activité Dans un premier temps (risque)

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : info@361sale.com
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.