Pourquoi votre PWA Ionic est lente : 3 erreurs à corriger en priorité

Dans la plupart des cas, une PWA Ionic paraît lente pour trois raisons : trop de JavaScript charge dès le premier écran, le cache ou le service worker sont mal réglés, ou le rendu Angular travaille trop à chaque interaction.

La bonne réponse n’est pas de tout optimiser partout, mais de repartir d’un parcours précis : la page qui charge trop lentement, la liste qui saccade, l’écran qui se met mal à jour, ou la version qui reste bloquée alors qu’un nouveau build a été publié.

Une PWA peut obtenir un score correct sur un audit rapide tout en restant pénible à utiliser au quotidien. C’est pour cela qu’il faut lire la performance à la fois côté métriques et côté perception réelle : temps d’ouverture, réactivité, fluidité, stabilité du cache et confiance au moment des mises à jour.

Demander un premier échange

Avant d’optimiser : mesurer le bon problème

Le réflexe le plus rentable n’est pas de partir du framework. Il faut d’abord regarder ce que l’utilisateur ressent et ce que les outils confirment : quelle page ouvre lentement, quel écran est pénible sur réseau mobile, quel flux semble bloqué après mise à jour, quel composant fait chuter la fluidité.

• mesurer le premier écran réellement le plus consulté ;
• vérifier le poids du shell, des routes et des librairies lourdes ;
• contrôler la stratégie de cache des assets et des appels API ;
• observer le rendu sur téléphone moyen, pas seulement sur poste de dev ;
• lire les retours produit : lenteur, écran figé, mauvaise mise à jour, scroll instable.

1. Trop de JavaScript dès le premier écran

C’est souvent la cause la plus visible. Trop de code part au chargement initial, même quand l’utilisateur n’a besoin que d’un écran simple. La PWA paie alors un coût immédiat en téléchargement, parsing, exécution et hydratation.

Symptômes : premier écran lent, TTI élevé, route d’accueil trop lourde, interactions retardées après affichage.

Ce qu’il faut corriger côté Angular et Ionic

• Lazy routes standalone avec loadComponent() ou loadChildren() ;
• vues différées pour les blocs secondaires via @defer ;
• imports dynamiques pour les librairies lourdes : cartes, graphiques, éditeurs, PDF, modules métier secondaires ;
• budgets et build production activés pour éviter la dérive silencieuse des bundles.

Le vrai gain vient souvent d’un choix simple : ne charger au premier écran que ce qui sert au premier écran. Tout le reste doit attendre un scroll, une navigation ou une intention claire.

// app.routes.ts
export const routes = [
  { path: '', loadComponent: () => import('./home/home.page').then(m => m.HomePage) },
  { path: 'details/:id', loadChildren: () => import('./details/routes').then(m => m.DETAILS_ROUTES) }
];

<!-- Vue différée -->
@defer (on viewport) {
  <app-heavy-chart />
} @placeholder {
  <ion-skeleton-text animated />
}

2. Un cache ou un service worker mal cadré

Une PWA peut aussi paraître lente parce qu’elle est instable dans son comportement : ancienne version encore visible, données obsolètes, assets qui ne se mettent pas à jour au bon moment, ou expérience confuse au redéploiement.

Symptômes : app qui ne se met pas à jour, données obsolètes, comportement différent selon le device ou le moment de la journée.

Ce qu’il faut cadrer côté Angular Service Worker

• configurer proprement ngsw-config.json, pas le laisser en mode minimal par défaut ;
• mettre les assets critiques en prefetch et les médias plus lourds en lazy ;
• traiter l’API en stratégie de fraîcheur adaptée au métier, souvent network-first ;
• prévoir un message de mise à jour clair via SwUpdate pour éviter l’impression d’application bloquée.

Beaucoup d’équipes sous-estiment ce sujet parce que la PWA “fonctionne”. Pourtant, un cache mal pensé abîme directement la confiance : l’utilisateur n’est plus certain de ce qu’il voit, ni de savoir si la version affichée est la bonne.

// ngsw-config.json (extrait)
{
  "assetGroups": [
    { "name": "app", "installMode": "prefetch",
      "resources": { "files": ["/*.css","/*.js","/index.html"] } },
    { "name": "assets", "installMode": "lazy",
      "resources": { "files": ["/assets/**"] } }
  ],
  "dataGroups": [
    { "name": "api", "urls": ["https://api.exemple.com/**"],
      "cacheConfig": { "strategy": "freshness", "maxSize": 100,
                       "maxAge": "1d", "timeout": "10s" } }
  ]
}

3. Un rendu Angular trop coûteux

Même avec un bundle maîtrisé et un cache propre, la sensation de lenteur peut revenir si Angular travaille trop à chaque interaction. Cela se voit surtout sur mobile, dans les listes, les filtres, les dashboards et les écrans denses.

Symptômes : scroll saccadé, listes lentes, filtres qui répondent mal, écran qui rerend trop souvent pour peu de valeur visible.

Les correctifs les plus utiles

• passer les composants clés en ChangeDetectionStrategy.OnPush ;
• utiliser les Signals pour maîtriser l’UI réactive ;
• suivre correctement les listes avec @for (...; track item.id) ou un trackBy propre ;
• basculer en virtual scroll dès que le volume le justifie.

Ce point fait souvent la différence entre une PWA simplement “chargée” et une PWA perçue comme lourde. L’utilisateur ne voit pas la change detection. Il ressent seulement que l’écran répond mal.

import { ChangeDetectionStrategy, Component } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';

@Component({
  selector: 'app-list',
  standalone: true,
  template: `
    <ul>
      @for (item of items(); track item.id) {
        <li>{{ item.label }}</li>
      }
    </ul>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ListComponent {
  readonly items = toSignal(this.svc.items$);
  constructor(private readonly svc: ItemsService) {}
}

Ordre de correction conseillé en pratique

Quand il faut agir vite, l’ordre le plus rentable est souvent le même.

1. identifier la route ou le parcours qui pénalise le plus l’usage réel ;
2. alléger le chargement initial du shell et des dépendances secondaires ;
3. remettre au propre le cache, le service worker et le flux de mise à jour ;
4. traiter ensuite les composants lourds, les listes et les rerenders inutiles ;
5. retester sur téléphone moyen, réseau mobile et version publiée, pas seulement en local.

Quand un audit plus large devient nécessaire

Si la PWA existe déjà depuis un moment, avec beaucoup de composants, de plugins, de routes métier et de correctifs successifs, les trois erreurs ci-dessus peuvent être présentes en même temps. Dans ce cas, un diagnostic plus large évite de corriger un symptôme tout en laissant le problème structurant intact.

Réponse courte

Une PWA Ionic rapide, ce n’est pas seulement une question de framework. C’est un premier écran plus léger, un cache fiable, une mise à jour compréhensible et moins de travail de rendu côté Angular.

Si votre application mobile web est déjà lancée, le plus utile est de partir du parcours réellement lent, du poids réel du bundle et des zones où l’expérience se dégrade le plus sur téléphone.

Aller plus loin

Articles liés