Réduire le JavaScript inutilisé sur PrestaShop : guide complet

Pourquoi Lighthouse signale du JavaScript inutilisé sur PrestaShop

Lorsque vous passez votre boutique PrestaShop dans Google Lighthouse ou PageSpeed Insights, l'alerte "Reduce unused JavaScript" apparaît quasi systématiquement. Ce n'est pas un bug : c'est la conséquence directe de l'architecture front-end de PrestaShop, qui charge un bundle JavaScript global (theme.js) et les scripts de chaque module sur toutes les pages, même quand ils ne servent pas.

Concrètement, si votre page d'accueil charge le JS du module de paiement ou du panier alors que le visiteur n'a encore rien ajouté, ces kilo-octets sont téléchargés, parsés et compilés pour rien. Sur mobile, l'impact sur le Time to Interactive peut atteindre plusieurs secondes.

Étape 1 : diagnostiquer avec l'onglet Coverage de Chrome DevTools

Avant de toucher au code, il faut mesurer précisément ce qui est réellement utilisé. Chrome DevTools intègre un outil parfait pour cela.

Comment utiliser Coverage

1. Ouvrez Chrome DevTools (`F12` ou `Ctrl+Shift+I`)
2. Ouvrez le panneau **Coverage** : `Ctrl+Shift+P` → tapez "Coverage" → sélectionnez "Show Coverage"
3. Cliquez sur le bouton d'enregistrement (rond) puis rechargez la page
4. Analysez les résultats :

- En bleu : le code effectivement exécuté sur cette page

- En rouge : le code chargé mais jamais utilisé

Cette cartographie vous donne une base factuelle. Un fichier theme.js avec 70 % de rouge est un candidat prioritaire à l'optimisation.

Astuce : testez plusieurs pages (accueil, fiche produit, panier, checkout) car un script inutile en homepage peut être critique en checkout.

Étape 2 : commencer par le CSS (le quick win)

Le CSS inutilisé est beaucoup plus simple à éliminer que le JavaScript, et l'impact sur le rendu est souvent spectaculaire. Commencez par là.

Méthode avec PurgeCSS

PurgeCSS analyse vos templates et supprime automatiquement les sélecteurs CSS non utilisés :

npm install -D purgecss

Créez un fichier purgecss.config.js à la racine de votre thème :

module.exports = {
  content: [
    './templates/**/*.tpl',
    './modules/**/*.tpl',
    './_dev/js/**/*.js'
  ],
  css: ['./assets/css/theme.css'],
  safelist: {
    // Classes dynamiques générées par PrestaShop
    standard: [/^js-/, /^ps-/, /^block-/],
    deep: [/modal/, /dropdown/, /carousel/]
  }
}

Attention PrestaShop 8.x : le thème classic a été remanié. Vérifiez que votre safelist couvre les nouvelles classes introduites dans Hummingbird si vous l'utilisez.

Étape 3 : désactiver les modules inutiles par page via les positions

PrestaShop permet de greffer et dégreffer des modules hook par hook. C'est le levier le plus rapide pour réduire le JS inutilisé sans toucher au code.

En back-office

1. Allez dans **Design → Positions**
2. Identifiez les modules qui injectent du JS sur des pages où ils ne servent pas
3. Utilisez les **exceptions par page** pour exclure certaines pages

Par exemple, un module de comparaison de produits n'a rien à faire sur la page de confirmation de commande. Un slider en homepage n'a pas besoin d'être chargé sur les fiches produit.

Via le code (plus propre)

Dans votre thème, vous pouvez conditionner le chargement d'un asset :

// Dans un module : ne charger le JS que sur les pages produit
public function hookActionFrontControllerSetMedia($params)
{
    $controller = $this->context->controller;
    if ($controller instanceof ProductController) {
        $this->context->controller->registerJavascript(
            'module-monmodule-product',
            'modules/'.$this->name.'/views/js/product.js',
            ['priority' => 200, 'attribute' => 'defer']
        );
    }
}

Sur PrestaShop 8.x, cette approche reste identique. L'API registerJavascript est stable depuis la 1.7.

Étape 4 : optimiser theme.js via Webpack

C'est l'étape la plus impactante mais aussi la plus délicate. Le fichier theme.js est un bundle Webpack qui inclut toutes les dépendances du thème : jQuery, les composants Bootstrap, les librairies d'animation, etc.

Analyser le bundle

cd themes/votre-theme/_dev
npm install
npm install -D webpack-bundle-analyzer

Ajoutez dans webpack.config.js :

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  // ... config existante
  plugins: [
    new BundleAnalyzerPlugin({ analyzerMode: 'static' })
  ]
};

Lancez npm run build : une page HTML interactive s'ouvre, montrant la taille de chaque dépendance dans le bundle.

Supprimer les librairies inutiles

Les coupables classiques :

• **Moment.js** (300 Ko) → remplacez par `dayjs` (2 Ko) ou supprimez si non utilisé
• **Velocity.js** → souvent remplaçable par des transitions CSS
• **Bootstrap JS complet** → n'importez que les composants utilisés

// Avant : import de tout Bootstrap
import 'bootstrap';

// Après : import sélectif
import 'bootstrap/js/dist/modal';
import 'bootstrap/js/dist/dropdown';
import 'bootstrap/js/dist/collapse';

Code splitting avec Webpack

Pour les fonctionnalités lourdes utilisées sur certaines pages seulement :

// Chargement dynamique du slider uniquement en homepage
if (document.querySelector('.homepage-slider')) {
  import(/* webpackChunkName: "slider" */ './components/slider')
    .then(module => module.default.init());
}

Webpack créera automatiquement un chunk séparé qui ne sera chargé que quand nécessaire.

PrestaShop 8.x et le thème Hummingbird

Le nouveau thème Hummingbird de PrestaShop 8 abandonne jQuery au profit de JavaScript vanilla et adopte une architecture plus modulaire. Si vous démarrez un nouveau projet sur PS 8.x, Hummingbird offre une base bien plus légère que Classic. Pour les projets existants migrant vers 8.x, c'est l'occasion de repenser entièrement la stack front-end.

Étape 5 : attributs de chargement (defer et async)

Même sans recompiler Webpack, vous pouvez améliorer le chargement perçu :

// Dans votre thème ou module
$this->context->controller->registerJavascript(
    'mon-script',
    '/modules/monmodule/views/js/front.js',
    [
        'priority' => 200,
        'attribute' => 'defer',  // ou 'async'
        'server' => 'local'
    ]
);

• **`defer`** : le script est téléchargé en parallèle et exécuté après le parsing HTML (ordre préservé)
• **`async`** : le script est téléchargé en parallèle et exécuté dès que disponible (ordre non garanti)

Privilégiez defer pour la plupart des cas. Réservez async aux scripts totalement indépendants (analytics, tracking).

Résumé de la stratégie d'optimisation

ActionDifficultéImpactRisque Exceptions de position par pageFacileMoyenFaible PurgeCSS sur le CSSFacileFortMoyen Attributs defer/asyncFacileMoyenFaible Code splitting WebpackAvancéFortMoyen Refonte complète du bundleExpertTrès fortÉlevé

La règle d'or : commencez par le CSS et les positions de modules (gains rapides, risque faible), puis attaquez le JavaScript progressivement avec Webpack. Ne refaites jamais tout d'un coup — chaque modification doit être testée isolément pour éviter les régressions fonctionnelles.