.

Depuis le début Fasterize optimise les pages, notamment en cachant les ressources et les pages qui sont cachables.

Cependant, lorsque nous étions dans le cas d’un test A/B (mesurez l’impact de Fasterize), nous n’étions pas en mesure d’appliquer ce test A/B sur les pages cachables.

Explication :

schema AB caching

Mais ça, c’était avant !

Avec le développement du cache pour l’A/B testing, cette histoire est du passé !

Désormais, pour accéder aux pages cachables, l’utilisateur doit être équipé d’un cookie (qui indique s’il fait partie de la population optimisée ou non).
Dans le cas où il s’agit d’un nouvel utilisateur (et que par définition, il ne dispose pas de cookie), sa requête transitera par le moteur fasterize qui l’attribuera à une population par l’intermédiaire d’un cookie. L’utilisateur aura donc accès à la page correspondant à sa population et se trouvant dans le cache* :

Si ce même utilisateur revient dans quelques jours, il sera déjà équipé de son cookie et sa requête ne transitera plus par le moteur Fasterize. La page optimisée cachée lui sera directement servie :

Cela nous permet de tracker les utilisateurs déjà équipés d’un cookie afin de connaître le comportement de leur navigateur et de l’internaute selon sa population (optimisée ou non).

L’avantage de cette nouvelle feature

Nos méthodes d’A/B testing se voient clairement améliorées. Désormais nous pouvons intégrer les pages cachables dans nos tests A/B et récupérer ainsi plus d’informations sur les effets de Fasterize sur votre site.


*Pour que la page optimisée soit sauvergardée dans le cache, le tout premier utilisateur de notre A/B test doit faire le travail de chercher l’information directement sur le serveur, comme indiqué dans le chemin ci-dessous. Grâce à lui, tous les utilisateurs suivant pourront accéder aux pages optimisées directement via le cache.

 

Découvrez l’impact de la webperf sur votre site et votre business !

Télécharger le livre blanc