Optimisations asynchrones

WP Rocket propose quelques optimisations asynchrones. Cela signifie que bien que les optimisations soient appliquées automatiquement, elles ne sont pas instantanées et nécessitent une série d'étapes (et du temps) avant d'être appliquées sur un site.

Les fonctionnalités suivantes sont appliquées de manière asynchrone :

Vue d'ensemble des fonctionnalités

WP Rocket utilise une approche asynchrone. Actuellement, cette approche asynchrone est appliquée sur les options  Supprimer les ressources CSS inutilisées et Chargement Asynchrone du CSS.

En général, une optimisation asynchrone suit les étapes suivantes :

  1. Démarrage du processus avec un déclencheur
  2. Envoi d'informations à l'API
  3. Vérification du statut
  4. Répétition, si nécessaire
  5. Application de l'optimisation

Attention ! Il s'agit d'un article de niveau avancé dédié à la documentation de l'approche asynchrone en profondeur.

Conditions requises

WP Cron ou une tâche Cron côté serveur (de préférence) est très important pour cette approche de WP Rocket. Voir cet article pour plus d'informations.

Approche asynchrone pour Supprimer les ressources CSS inutilisées

L'approche asynchrone pour la suppression des ressources CSS inutilisées utilise les étapes spécifiques suivantes pour la génération et l'application des ressources CSS inutilisées :

  1. Démarrer le processus avec un déclencheur

    La visite d'une page non mise en cache génère le cache de la page. Si l'option Supprimer les ressources CSS inutilisées est activée, cela déclenchera la génération des feuilles de style CSS utilisées pour cette page.

    La visite peut être effectuée par le Préchargement ou par un visiteur.
  2. Envoi d'informations à l'API

    Le plugin envoie l'URL de la page à l'API. Le plugin envoie l'URL de la page à l'API. Avec le cache Mobile, le plugin enverra également des informations indiquant si la demande est destinée à un ordinateur de bureau ou à un téléphone portable.

  3. Vérification de l'état

    Après 60 secondes, le cron de WP Rocket appellera l'API externe pour demander l'état des demandes.

    Dans la base de données, chaque entrée aura un statut qui est défini en fonction de la réponse de l'API.

  4. Répétition, si nécessaire

    Si la génération du CSS utilisé échoue la première fois, WP Rocket va réessayer de générer le CSS jusqu'à 5 fois supplémentaires.

    Pour éviter de surcharger le processeur, le temps d'attente entre chaque essai sera progressivement incrémenté.

    Si la génération échoue après la 5ᵉ tentative, le CSS utilisé pour l'URL spécifique sera marqué comme "échoué" dans la base de données et WP Rocket réessayera de générer le CSS utilisé dans ces cas :

    • Après 3 jours.
    • Le CSS utilisé pour une URL spécifique est effacé en utilisant l'élément de menu de la barre d'administration "Effacer le CSS utilisé pour cette URL" lors de la visite de l'URL dans le back-end.
    • L'ensemble du CSS utilisé est effacé en utilisant l'élément de menu "Effacer les CSS utilisés" de la barre d'administration tout en visitant la page des paramètres de WP Rocket.
    • L'effacement automatique des CSS utilisés a lieu.
  5. Application de l'optimisation

    Si l'API indique que les CSS utilisés pour une page sont disponibles, lors de la prochaine visite, le cache de cette page sera effacé afin qu'un nouveau cache puisse être généré et qu'il comprenne les CSS utilisés résultants.

    Là encore, cette visite peut être déclenchée par un utilisateur ou par le Préchargement.

Notes techniques sur l'approche asynchrone de la suppression des ressources CSS inutilisées

  • La base de données de votre site stockera une entrée pour chaque demande d'optimisation dans une table nommée wpr_rucss_used_css  ;(une entrée pour chaque URL).
  • Les demandes d'optimisation sont envoyées à l'outil externe de WP Rocket, qui traite chacune d'entre elles comme un travail.
    • L'outil externe a pour API_URL nom https://saas.wp-rocket.me/.
  • L'API répondra et la valeur de la colonne status dans le wpr_rucss_used_css tableau sera mise à jour en conséquence pour chaque entrée.
  • La colonne wpr_rucss_used_css table status aura l'une de ces cinq valeurs possibles pour chaque entrée :
    • to-submit - Statut initial pour toutes les pages qui sont déclenchées pour la génération de Used CSS, ce qui signifie que la page doit avoir Used CSS généré, mais que le traitement n'est pas encore planifié.
    • pending - État des pages qui ont été soumises pour être traitées dans le générateur, ce qui signifie que le traitement est programmé mais n'a pas encore commencé.
    • in-progress - Statut des pages dont le CSS utilisé est en cours de traitement par le générateur.
    • completed - État confirmant que le générateur a créé avec succès le CSS utilisé pour l'URL.
    • failed - Statut lorsqu'une requête n'a pas abouti, c'est-à-dire qu'elle n'envoie pas un code de statut 200 (OK). Dans ce cas, les colonnes error_code et error_message afficheront plus de détails.
  • L'événement cron rocket_rucss_on_submit_jobs traitera et contrôlera combien de nouvelles URL peuvent être envoyées au générateur Used CSS (pending status) dans chaque lot.
  • Le nombre maximum d'URL qui peuvent être en attente état à un moment donné est fixé à 300 par défaut. 
    • Cette valeur est calculée comme étant 3 fois le nombre de la rocket_saas_pending_jobs_cron_rows_count valeur du filtre (qui est de 100 par défaut).
    • Cette limite est en place parce que si le nombre total de travaux en attente devient trop élevé, cela peut entraîner des erreurs de génération de CSS Used.
  • Toutes ces demandes d'optimisation et ces vérifications d'état reposent sur WP Cron ou un cron côté serveur (de préférence).
  • Si une réponse revient comme complété cela signifie :
    • Le CSS utilisé est généré et prêt à être appliqué, de sorte que le cache de l'URL sera vidé lors de la prochaine visualisation de la page.
    • Les hachages des entrées seront stockés dans la base de données dans la table wpr_rucss_used_css 
      • .
    • Le CSS utilisé est stocké sur le disque de votre serveur dans le /cache/used-css/1/ dossier. Si vous utilisez WordPress multisite, le dossier nommé /1/ changera pour refléter le numéro du site.
  • Si la génération de Used CSS échoue la première fois, cela signifie que :
    • Des tentatives supplémentaires de génération de Used CSS pour la page seront effectuées, pour un maximum de 5 tentatives au total. Les 5 tentatives supplémentaires ne seront effectuées que pour les URL dont la génération de Used CSS a échoué en raison d'un problème temporaire, mais elles n'auront pas lieu si l'URL ne remplit pas les conditions de base.
    • Si la réponse à la demande n'est toujours pas satisfaisante après les cinq tentatives, le statut de cette page reste failed et les autres pages sont traitées.
    • Pour les pages dont le statut est failed, la génération du CSS utilisé sera réessayée soit après 3 jours, soit après avoir effacé le CSS utilisé de cette entrée (ou de toutes les entrées de CSS utilisé).

Filtres disponibles pour Supprimer les ressources CSS inutilisées

Les filtres suivants sont disponibles pour personnaliser la fonction Supprimer les ressources CSS inutilisées :

  • rocket_saas_pending_jobs_cron_rows_count - Spécifiez le nombre de nouvelles pages que WP Rocket planifiera pour le traitement (défini sur pending le statut) dans chaque lot.
    • La valeur par défaut est 100 URLs.
  • rocket_saas_pending_jobs_cron_interval - Définissez l'intervalle de temps entre chaque demande de programmation de pages supplémentaires à traiter.
    • La valeur par défaut est 60 secondes.
  • rocket_rucss_max_pending_jobs - Définit le nombre maximum d'URL qui peuvent être en pending état à un moment donné.
    • La valeur par défaut est 300, ce qui correspond à 3 fois la valeur du rocket_saas_pending_jobs_cron_rows_count filtre.
Cela a-t-il répondu à votre question ? Merci pour votre retour :) Une erreur est survenue lors de l’envoi de votre retour. Veuillez réessayer plus tard.