Réponse courte

Visez un premier écran sous environ 200 Ko, diffusez les réponses longues en flux au lieu de les attendre, et mettez en cache tout ce qui ne change pas d'un utilisateur à l'autre. Partez du principe que la connexion se coupera au milieu d'une requête, et traitez ce cas plutôt que d'afficher une erreur.

La contrainte qui commande tout

C'est la latence, pas le débit, qui donne l'impression qu'une connexion est cassée. Une page qui a besoin de six allers-retours successifs avant d'afficher quoi que ce soit paraîtra lente en données mobiles, quelle que soit la taille des fichiers. Chaque dépendance à résoudre avant le premier affichage coûte un aller-retour complet.

La première question sur un écran n'est donc pas « combien pèse-t-il » mais « combien de choses doivent se produire dans l'ordre avant que l'utilisateur voie quelque chose ».

Les budgets que nous nous fixons

ÉlémentBudgetPourquoi
Premier écran, total≈ 200 KoEnviron une seconde de contenu utile sur une connexion faible
Polices1 famille, 2 graissesChaque graisse supplémentaire est un téléchargement bloquant de plus
Image principale< 120 KoServie en responsive ; un téléphone ne doit jamais charger la taille bureau
VidéoPas au premier chargementImage d'attente d'abord ; vidéo seulement si la connexion le permet

Ce sont des budgets, pas des lois. L'important est que quelqu'un ait fixé un chiffre à l'avance, pour que le dépassement soit un arbitrage conscient et non un accident.

Diffuser plutôt qu'attendre

Les réponses d'IA sont lentes par nature : une réponse longue peut prendre plusieurs secondes à générer. Attendre l'ensemble avant d'afficher quoi que ce soit transforme cinq secondes de génération en cinq secondes d'écran vide. Diffuser les mots au fur et à mesure transforme cela en une réponse qui commence en moins d'une seconde et se termine au même moment.

La durée totale n'a pas changé. L'expérience est complètement différente.

Respecter les signaux du navigateur

Sur ce site, la vidéo d'accueil n'est attachée qu'après ces vérifications. Les utilisateurs en Save-Data ou en 2G/3G reçoivent une image d'attente et ne téléchargent rien.

Partir du principe que la connexion tombe

En données mobiles, les requêtes échouent couramment : un tunnel, un ascenseur, un changement de cellule. La différence entre un outil auquel on fait confiance et un outil qu'on abandonne, c'est ce qui se passe ensuite. Conservez la saisie si l'envoi échoue. Rendez la reprise évidente. Ne videz jamais un formulaire parce que le réseau a cligné des yeux.

Ce que ce n'est pas

Ce n'est pas un plaidoyer pour des sites laids et minimaux. C'est un plaidoyer pour décider de ce qui charge en premier. Une page lourde qui affiche immédiatement du contenu utile et charge le reste après convient très bien. Une page légère qui n'affiche rien pendant quatre secondes, non.

Voir la page de service : Site web avec IA intégrée pour entreprises algériennes.

Questions fréquentes

Comment optimiser une application web pour des données mobiles lentes ?

Budgétez le premier écran autour de 200 Ko, réduisez le nombre de requêtes successives avant le premier affichage, diffusez les réponses longues en flux, servez des images responsives et repoussez la vidéo derrière une vérification de connexion.

Quel poids viser pour un premier chargement ?

Environ 200 Ko pour tout ce qui est nécessaire à l'affichage d'un contenu utile. Au-delà de la taille, c'est le nombre d'allers-retours à terminer avant le premier affichage qui compte le plus sur une connexion à forte latence.

Faut-il lancer une vidéo automatiquement en données mobiles ?

Pas sans vérifier. Lisez navigator.connection.saveData et effectiveType, et respectez prefers-reduced-motion. Les utilisateurs sur connexion contrainte doivent recevoir une image d'attente et ne rien télécharger de plus.

Un problème qui mérite d'être résolu ?

Dites-nous ce que vous cherchez à corriger, simplement. Si l'IA n'est pas le bon outil, nous vous le dirons.

Parlons-en