J'intègre votre équipe et nous rendons votre site rapide

Cela dépend de l'argent qui transite par votre site. Loop Earplugs a gagné environ 800ms sur mobile et la conversion au checkout a augmenté de 7 %. Je ne peux pas vous promettre 7 %, mais le RUM montre ce que chaque correction a fait sur la métrique et votre analytics montre l'impact sur les revenus. Vous aurez les deux.

Un peu. Les Core Web Vitals sont un facteur de ranking, mais un petit : le contenu pertinent passe avant, et la vitesse départage des pages au coude à coude. Le plus gros gain se situe après le clic. Un site plus rapide perd moins de visiteurs et convertit davantage ceux qui restent, et cela se voit dans vos revenus, que Google vous fasse monter ou non.

Aux entreprises avec leurs propres développeurs, du vrai trafic et un site où la vitesse a un impact sur les revenus. Principalement l'e-commerce, les applications SaaS où les clics paraissent lents, et les éditeurs de presse avec beaucoup de publicités. Vous n'avez pas vos propres développeurs et aucune agence ne construit pour vous ? Alors un audit ou une correction rapide est un meilleur point de départ.

Non. Quiconque garantit un score avant de regarder votre site joue aux devinettes. Mon but est de valider les Core Web Vitals au 75e centile sur les pages qui vous rapportent de l'argent. C'est ce que Google mesure, et c'est ce que vos visiteurs ressentent.

La plupart des agences font un peu de tout, et la performance est un point sur la liste. C'est la seule chose que je fais. Les problèmes complexes sont rarement sur une checklist : l'hydration dans Next.js, des dizaines de scripts tiers sur un site média, des publicités qui provoquent des layout shifts au chargement. Nous avons tous notre spécialité. Voici la mienne.

Oui, c'est inclus dans la consultance. Si votre propre RUM montre déjà quel élément ou script est lent, nous pouvons l'utiliser à la place.

Presque toutes. Next.js, Nuxt, Magento, Salesforce Commerce Cloud, Shopify, WordPress, ou un site PHP que quelqu'un a construit en 2012. Le navigateur se moque de ce qui a généré la page, et le navigateur est là où je travaille. Sur une plateforme hébergée comme Shopify, vous ne pouvez pas changer la plateforme elle-même, mais le thème, les apps et les scripts qu'elles ajoutent sont à vous, et la plupart des problèmes s'y trouvent.

Ce score, c'est Lighthouse : un test en lab data sur un seul téléphone lent simulé. Google regarde les field data, ce que vos vrais visiteurs expérimentent au 75e centile, et c'est sur ça que je travaille. Le score Lighthouse monte généralement en cours de route, mais je ne cours pas après. Un site peut obtenir 95 et quand même échouer aux Core Web Vitals, et inversement.

Je trouve ce qui tourne sur le main thread quand quelqu'un clique. L'API Long Animation Frames (LoAF) m'indique quel script et quelle fonction. Ensuite, nous découpons ce travail, nous l'écartons ou nous le supprimons.

Presque jamais. Généralement, ce sont quelques composants lourds, l'ordre de chargement des scripts, ou la façon dont la page hydrate. Changer cela coûte beaucoup moins cher qu'une réécriture, et vous voyez le résultat bien plus tôt.

Pas encore de RUM, ou le vôtre ne peut pas montrer quel élément ou script est lent ? Alors j'ajoute CoreDash. Il est conçu exactement pour ce travail. Pour chaque événement LCP, INP et CLS, il montre quel élément, script ou ressource l'a causé. Vous voyez l'effet d'une correction pour les vrais visiteurs en un jour, au lieu d'attendre que la moyenne glissante de 28 jours de Google se mette à jour. Et il n'y a pas de limite sur le nombre d'URL suivies ni sur la durée de conservation des données.

Oui. J'aime travailler avec les agences, et avec tous les autres acteurs impliqués. L'agence construit, je trouve les problèmes, je les mets dans l'ordre et je vérifie chaque correction, exactement comme avec votre propre équipe. Vous êtes l'agence ? Alors voici comment je travaille avec les agences.

Des constatations sous forme de tickets dans votre propre système, des corrections qui sont en ligne, des budgets de performance dans votre pipeline CI/CD, du monitoring et des alertes sur vos données RUM, et des développeurs qui comprennent pourquoi tout ça fonctionne.

De deux façons. Les budgets de performance dans votre pipeline de déploiement signalent un build qui ajoute des layout shifts ou bloque le main thread avant sa mise en ligne. Et les alertes sur vos données RUM vous disent quand quelque chose s'aggrave. CoreDash vérifie toutes les heures, mais ne déclenche une alerte que lorsqu'il y a assez de données pour être sûr, vous ne courez donc pas après de faux positifs. Vous êtes quand même au courant des semaines avant la Search Console.

Un audit vous dit ce qui ne va pas et dans quel ordre le corriger. La consultance reste jusqu'à ce que ce soit corrigé.

Votre équipe prend le relais. Il y a aussi un suivi, à partir de 1 500 € par mois pour environ un jour de mon temps : je surveille vos données RUM, je vous dis quand quelque chose ralentit, et chaque trimestre nous décidons de la suite.

D'un accès à votre dépôt (GitHub, GitLab, ou ce que vous utilisez), d'un environnement de staging et de votre analytics. Pas de semaines de réunions d'onboarding. Une fois que je suis dedans, je commence, et vous recevez généralement les premières constatations dans les 5 jours ouvrés.

D'une semaine à six mois. Cela dépend de ce qui ne va pas et de la vitesse à laquelle votre équipe livre. La plupart prennent moins de temps que ce que les gens imaginent : 60 % de mes missions sont terminées en moins d'un mois. La durée exacte est dans le périmètre, avant de commencer.

Vous voyez les changements dans vos données RUM un jour après le déploiement. Les chiffres ont besoin d'assez de visites avant de signifier quoi que ce soit, donc les pages très visitées le montrent plus tôt que les pages calmes. Dans tous les cas, vous le savez des semaines avant que le rapport CrUX de Google ne se mette à jour.

Oui. Nous ne retirons pas vos tags, nous changeons comment et quand ils chargent. Les publicités peuvent toujours respecter les exigences de visibilité sans bloquer le main thread ni décaler la mise en page. DPG Media, Aleteia et Who What Wear ont gardé leurs revenus publicitaires et passé les Core Web Vitals.