WordPress et Shopify: refonte rapide, INP et checkout extensible
Refondre un site e-commerce n’est plus seulement une question de design ou de CMS : c’est un sujet de réactivité perçue, de parcours d’achat et de capacité à déployer vite sans casser l’existant. Entre WordPress (souvent côté contenu/landing pages) et Shopify (souvent côté transaction), les arbitrages se font de plus en plus sur des critères mesurables : performance réelle, maintenabilité et évolutivité du checkout.
Depuis 2024, deux évolutions structurent ces décisions : d’un côté, INP devient la métrique officielle de “réactivité” des Core Web Vitals (en remplacement de FID) ; de l’autre, Shopify accélère la transition vers un checkout extensible “app-based” et met fin progressivement aux customisations historiques via checkout.liquid et scripts legacy. Résultat : une “refonte rapide” doit s’organiser autour d’un plan technique et d’un calendrier produit.
1) INP : la réactivité devient la nouvelle boussole des refontes
Le 12/03/2024, Google a officiellement fait d’INP (Interaction to Next Paint) la métrique de réactivité des Core Web Vitals, en remplacement de FID. L’annonce est documentée à la fois côté web.dev et côté Google Search Central, avec une date de bascule explicite au 12 mars 2024.
Concrètement, INP mesure la latence ressentie lors des interactions (clic, tap, saisie) jusqu’au prochain rendu visible, et pas uniquement un “premier input” isolé. Pour une refonte, cela évite l’illusion d’une page “rapide” au chargement mais pénible dès qu’on interagit (menus, filtres, accordéons, variations produit, formulaires).
Cette bascule change aussi la manière de piloter un chantier : au lieu de se focaliser uniquement sur des optimisations initiales (chargement, FCP/LCP), on doit mesurer et améliorer le comportement en session réelle. C’est particulièrement vrai sur des stacks WordPress + Shopify où les pages marketing (WP) et les pages transactionnelles (Shopify) doivent délivrer une expérience cohérente.
2) Seuils INP : un cadre simple pour décider “quoi optimiser”
Pour rendre INP actionnable, beaucoup d’équipes s’appuient sur des seuils largement repris : “bon” ≤ 200 ms, “à améliorer” entre 200 et 500 ms, “mauvais” > 500 ms. Ce cadre permet de prioriser les efforts et d’éviter les débats subjectifs du type “ça me semble fluide”.
Dans une refonte rapide, ces seuils servent de garde-fou : on peut livrer vite, mais on met des exigences minimales de réactivité sur les gabarits clés (home, catégories, fiche produit, panier, checkout, formulaires). Et on suit les régressions après mise en production, car INP est très sensible aux scripts tiers, aux widgets et aux logiques de tracking.
Un point important : INP dépend souvent d’encombrements JavaScript (long tasks), de rendu bloqué (styles), ou d’événements trop lourds sur la saisie (validation en direct, masques de champs, composants UI). Dit autrement, “refonte rapide” ne doit pas signifier “refonte qui empile des scripts” : le budget JS devient un livrable.
3) WordPress 6.5 : accélérer la production de pages sans sacrifier la qualité
Une refonte est souvent freinée par la capacité de l’équipe à produire et modifier des pages (landing pages, pages éditoriales, guides, comparatifs) sans surcoût technique. Sur ce terrain, WordPress 6.5 apporte des gains notables côté éditeur : environ 5× plus rapide sur la saisie, 2× plus rapide sur le chargement de l’éditeur, et jusqu’à -60% sur le chargement des patterns.
Ces améliorations ont un impact indirect mais réel sur la “refonte rapide” : si l’outil de production est plus fluide, on itère plus vite, on réduit la friction en interne, et on limite la tentation de “tout coder en dur”. Cela aide à industrialiser une bibliothèque de sections/patterns réutilisables, ce qui réduit aussi les risques de divergences front et donc de régressions INP.
Pour relier WordPress à l’objectif INP, l’enjeu est de maintenir une discipline : thèmes et blocs optimisés, limitation des plugins qui injectent du JS, et contrôle des assets (chargement conditionnel, suppression des dépendances inutiles). L’idée n’est pas “WordPress vs Shopify”, mais “WordPress pour publier vite, Shopify pour encaisser vite”, avec des contraintes de réactivité communes.
4) Shopify Checkout Extensibility : personnaliser sans casser les upgrades
Shopify positionne le “Checkout extensibility” comme une personnalisation du checkout basée sur des apps, “upgrade-safe”, avec exécution sandboxée (meilleure isolation/sécurité). L’objectif est clair : permettre des personnalisations sans toucher au code thème historique de checkout et sans compromettre l’évolution du produit checkout.
Du point de vue business, Shopify avance aussi une promesse : “jusqu’à 1% de conversion en plus en moyenne”. Qu’on prenne ce chiffre comme un ordre de grandeur ou comme un indicateur marketing, il rappelle surtout une réalité opérationnelle : un checkout standardisé, performant et maintenu peut convertir mieux qu’un checkout sur-customisé mais fragile.
Pour une refonte, cela change le mode de travail : on passe d’un “développement thème” (souvent très libre mais risqué) à une approche par extensions et surfaces autorisées. Il faut donc cartographier les besoins (upsell, règles de livraison, validations, affichage TVA, B2B, consentements) et vérifier leur équivalent via extensions, apps, Shopify Functions et pixels modernes.
5) Fin de checkout.liquid : calendrier et risques si vous ne migrez pas
Shopify a acté la fin de checkout.liquid pour les pages “in-checkout” à partir du 13/08/2024. Le Dev Changelog précise que checkout.liquid ne fonctionnera plus pour ces pages à partir de cette date, ce qui crée une contrainte de migration nette.
Le Changelog Shopify confirme également la dépréciation et une conséquence critique : si vous n’avez pas migré avant la deadline, il peut y avoir un “auto-upgrade vers un checkout non customisé”. Autrement dit, le risque n’est pas uniquement technique (erreurs), il est aussi produit (perte de parcours, suppression d’éléments de réassurance, rupture de tracking).
En pratique, une refonte “checkout” doit donc traiter la migration comme un projet à part entière, avec inventaire de toutes les customisations existantes (liquid, scripts, tags, pixels, validations, DOM hacks) et plan de remplacement. La communauté Shopify rappelle la philosophie : une solution “upgrade-safe”, intégrée à Shop Pay, et pensée pour convertir, mais cela implique d’accepter un cadre.
6) Thank you / Order status : extensibilité, extinction, et enjeu tracking
Shopify étend également Checkout Extensibility aux pages “Thank you” et “Order status”, avec un calendrier de bascule plus long : extinction post-checkout annoncée au 28/08/2025. Les communications Shopify mentionnent aussi la dépréciation sur ces pages de mécanismes legacy comme script tags, additional scripts et checkout.liquid.
Le Help Center Shopify précise une timeline opérationnelle : 28/08/2025 est la deadline pour remplacer ces pages (notamment pour les marchands Plus), et janvier 2026 marque le démarrage des upgrades automatiques, avec perte des customisations legacy. Shopify indique également un préavis (30 jours) avant l’auto-upgrade, ce qui impose de ne pas attendre “la dernière minute”.
Un point souvent sous-estimé en refonte : l’impact sur la donnée. Après la date limite, certains accès à la PII et certains événements/pixels via les mécanismes legacy peuvent être restreints. Il faut donc revalider le plan de mesure (analytics, ads, server-side si applicable), l’attribution, les tags de conversion et les besoins CRM, sinon on “réussit la refonte” mais on perd la capacité de piloter la croissance.
7) APIs Checkout stoppées au 01/04/2025 : anticiper la migration côté custom front
Au-delà du thème, Shopify a annoncé l’arrêt des Checkout APIs (endpoints REST Checkout et mutations Storefront Checkout) au 01/04/2025, avec migration requise vers la Storefront Cart API. Pour les apps, front-less ou intégrations sur mesure, c’est un jalon technique majeur.
Si votre refonte inclut un front custom (less, PWA, app mobile), la conséquence est immédiate : les flux de création/gestion du checkout doivent être repensés autour du panier (Cart) plutôt qu’autour d’anciens endpoints checkout. Shopify mentionne aussi le Checkout Sheet Kit côté mobile, ce qui influence l’architecture des apps et l’expérience de paiement.
Une refonte rapide bien cadrée intègre ces dates dans la roadmap : on évite de livrer en 2024-2025 une implémentation qui dépend d’APIs destinées à s’éteindre, et on sécurise la trajectoire (tests, rétrocompatibilité, plan de déploiement progressif). L’objectif est de réduire les “re-refontes” imposées par calendrier plateforme.
8) Méthode “refonte rapide” WordPress + Shopify : livrer vite, mesurer INP, sécuriser le checkout
Une approche efficace consiste à découpler : WordPress sert de moteur de contenu et de pages d’acquisition (SEO, campagnes, éditorial), tandis que Shopify porte l’achat (catalogue, panier, paiement) avec un checkout modernisé via Extensibility. Ce découpage permet d’accélérer la production sans compromettre la partie la plus critique : l’encaissement.
Côté performance, INP devient un KPI de release : on fixe une cible (idéalement ≤ 200 ms sur les gabarits clés), on instrumente (RUM, CrUX quand disponible), et on met en place un budget de scripts tiers. Le but est d’éviter que chat, AB tests et tags marketing ne dégradent la réactivité, surtout sur mobile.
Côté Shopify, on traite la migration comme une check-list : remplacement de checkout.liquid avant 13/08/2024 pour l’in-checkout, plan Thank you / Order status avant 28/08/2025, et refonte des intégrations dépendant des Checkout APIs avant 01/04/2025. La communauté Shopify souligne aussi les migrations adjacentes (ex. Scripts vers Functions) : les dépendances “historiques” doivent être identifiées tôt pour éviter les surprises en fin de projet.
WordPress et Shopify ne s’opposent pas : ils se complètent, à condition de refondre avec les bons critères. En 2024, la réactivité se pilote désormais avec INP (officiel depuis le 12/03/2024), ce qui pousse à concevoir des interfaces réellement fluides, pas seulement “rapides au chargement”.
En parallèle, Shopify impose un mouvement de fond vers Checkout Extensibility, avec des dates non négociables (checkout.liquid in-checkout dès le 13/08/2024, post-checkout au 28/08/2025, auto-upgrades dès janvier 2026, et arrêt des Checkout APIs au 01/04/2025). La meilleure refonte “rapide” est donc celle qui aligne performance (INP), calendrier plateforme, et architecture (contenu vs transaction) pour livrer vite… sans se retrouver à refaire dans 6 mois.