NouveauBlack Friday : 50 % de réduction sur votre premier paiement
Hébergement pour Perfmatters

L'hébergement de Perfmatters où les règles d'actifs survivent au cache.

Le téléchargement d'un script sur une page et non sur une autre signifie que les copies mises en cache de ces pages doivent différer.

Règles appliquées avant mise en cachePas de double réécritureVariantes par page mises en cache
Ordre correctRéécriture uniqueVariantes par pageSauvegardes quotidiennesSSL gratuitAssistance 24h/24 et 7j/7
Construit pour le contrôle des actifs

L'ordre des opérations est tout.

Les règles d'actif par page et la mise en cache pleine page interagissent dans une séquence exacte, et la plupart des configurations le font reculer.

Le déchargement se produit avant que la page ne soit mise en cache

Si le cache stocke la page en premier, les règles ne s'exécutent jamais pour personne, sauf le visiteur qui l'a réchauffé. Les décisions relatives aux actifs sont appliquées pendant la génération, de sorte que la copie cache est la version parée.

Première application

Un système réécrit des scripts, pas deux

Perfmatters et un optimiseur de plate-forme, tous deux reportant le même script produit des actifs qui se brisent sur certaines pages seulement. La réécriture est activée en un seul calque, délibérément.

Réécriture unique

Différentes pages, différentes sorties en cache

Une règle qui décharge un script slider partout sauf la page d'accueil signifie que ces pages diffèrent vraiment. Le cache les garde comme entrées séparées plutôt qu'une copie partagée.

Règles qui survivent à une purge

La configuration des actifs vit dans la base de données, pas dans le cache, donc le nettoyage du cache reconstruira les pages rognées plutôt que de restaurer les pages non trimées.

Défaire un déchargement qui a cassé quelque chose

Enlever un script dont dépendait une autre chose est une rupture subtile, souvent sur un modèle. Un point de restauration est plus rapide que de bisecter les règles.

Interactions

Deux optimiseurs, une page.

Le symptôme est une carte de score qui s'est améliorée sur la page que vous avez testée et nulle part ailleurs, parce que les règles ont couru une fois pendant la génération et le cache a gardé une copie d'avant.

  • Règles applicables aux actifs pendant la génération de pages
  • La réécriture de scripts est activée dans un seul calque
  • Différences par page mises en cache séparément
  • Configuration en dehors du cache
Application des règles
Par rapport à la cache
avant
Réécriture du script
Calque active
1
Variantes de page
Séparé
oui
Décharger l'audit
Modèles
en cours d'exécution
Pages réelles

Le gain doit atteindre chaque visiteur.

La taille de l'actif qui s'applique uniquement sur un cache manque est un artefact de mesure. Le nombre qui vaut la peine d'avoir est une page en cache livrée à quelqu'un qui ne l'a pas chaud.

Avant
la page est mise en cache
Une
reécriture des scripts de calque
Séparés
entrées par variante
MagicWP70 ms
Hôte partagé typique940 ms
Règles appliquées après mise en cache430 ms

Comparaison illusoire d'une page mise en cache avec les règles d'actifs appliquées. Vos chiffres dépendent du nombre de plugins et de la couverture des règles.

Configuration

Ce que nous changeons pour les plugins de contrôle des actifs

Rien de cela ne change ce que fait le plugin. Il change si ce qu'il fait atteint n'importe qui.

ParamètreNotre configurationPourquoi
Ordre des règlesDécisions sur les actifs appliquées pendant que la page est généréeUne page mise en cache avant que les règles ne s'exécutent conserve chaque script que les règles étaient censées supprimer, et seul le visiteur qui l'a réchauffé a vu la version parée.
Revoir les calquesReport de script et combinaison activés en un seul endroitDeux systèmes réécrivant le même actif produisent des sorties qui se brisent sur un sous-ensemble de pages, qui est proche de l'impossibilité d'attribuer ensuite.
Variantes de cachePages avec différentes règles d'actifs mises en cache séparémentLe téléchargement d'un script sur certains modèles signifie que ces réponses diffèrent vraiment, de sorte qu'une seule entrée de cache partagée doit être erronée pour l'un d'entre eux.
Stockage de configurationConservé dans la base de données plutôt que dérivé de la sortie en cacheLa suppression du cache devrait régénérer les pages taillées, et non pas les restaurer silencieusement jusqu'à ce que quelqu'un remarque.
Contrôles de dépendanceRévision par modèle avant que les règles ne soient mises en œuvreEnlever un script dont un autre dépendait de casser un seul modèle tranquillement, c'est-à-dire le mode de déchargement agressif.
Offres

Des tarifs simples et transparents.

Chaque offre comprend la migration gratuite, les sauvegardes quotidiennes, le SSL et l’assistance 24 h/24, 7 j/7.

MensuelAnnuel
Starter
Pour les sites personnels, blogs et portfolios.
16,67 USD/mois
200 $US par an · économisez 40 $US
  • 1 site WordPress
  • 10 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance par tickets
Démarrer l’essai gratuit
Pro★ Le plus populaire
Pour les entreprises en croissance et les boutiques très fréquentées.
66,67 USD/mois
800 $US par an · économisez 160 $US
  • 5 sites WordPress
  • 50 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance prioritaire par tickets
Démarrer l’essai gratuit
Enterprise
Pour les agences et les plateformes à fort trafic.
208,33 USD/mois
2 500 $US par an · économisez 500 $US
  • 20 sites WordPress
  • 200 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance dédiée
Démarrer l’essai gratuit
Questions fréquentes

Questions fréquentes.

Mes résultats se sont améliorés dans les tests, mais pas sur le terrain.
Habituellement, les règles s'exécutent pendant la génération de page et votre copie mise en cache les prédresse. Appliquée avant la mise en cache, la page stockée est la page taillée, donc chaque visiteur l'obtient.
Puis-je utiliser Perfmatters en plus de l'optimisation au niveau de l'hôte ?
Oui, mais un seul d'entre eux devrait réécrire des scripts. Deux systèmes en reportant le même atout produit une rupture sur un sous-ensemble de pages qui est très difficile à retracer.
Le déchargement par page casse-t-il la mise en cache ?
Non, mais cela signifie que ces pages diffèrent vraiment, donc elles sont mises en cache comme entrées séparées. Une copie partagée serait nécessairement erronée pour l'une des deux.
J'ai déchargé un script et un modèle cassé.
Restaurer et réintroduire plutôt que bisect. L'enlèvement d'un script un autre dépendait des pauses tranquilles et souvent sur une page que personne ne vérifie.

Faites en sorte que l'optimisation atteigne les visiteurs.

Déplacez le site à travers. Migration est libre, règles d'actif examinées.