mon-entreprise
mon-entreprise copied to clipboard
betagouv
PWA : consommation de bande passante
L'ajout de la PWA dans #2189 a entraîné une augmentation significative de la consommation de bande passante pour notre serveur Netlify.
C'était un problème que nous avions déjà avec le précédent essai d'ajout d'intégration PWA avant de retirer complètement cette fonctionnalité #1456.
Malheureusement Netlify donne une vue très très incomplète de la consommation de bande passante (Vercel le fait très bien...), le seul chiffre que j'ai trouvé est celui là :
Il faut donc se livrer à d'absurdes calculs pour essayer d'estimer la surconsommation de bande passante et l'impact sur la facturation :
Avec l'historique de mes mails j'obtiens 75% de bande passante consommée au 17 juillet, soit 750gb sur la période 17juin - 17 juillet. Vu qu'on a à peu près le même traffic sur la deuxième quinzaine de juillet on devrait avoir environ (14/31×750) = 340gb sur la période 18 juillet - 31 juillet, or Netlify nous donne 1100gb, soit une surconsommation de bande passante de 1100-340 = 760gb. La PR pwa a été mergée le 25 juillet, si on lui impute toute la surconsommation, ça veut dire qu'on a 760/7 ≈ 100gb de surconsommation par jour.
L’ordre de grandeur est vérifié avec l'onglet réseau des outils de développement, avant la PR le chargement du site implique le transfert de 760kB, après la PR pour un premier chargement sans cache j'obtiens 3.8MB (beaucoup moins ensuite une fois que le site et le worker sont à jour)
Netlify facture les 100gb au prix de 55€ https://www.netlify.com/pricing/, on peut donc estimer le coût de ce problème de surconsommation de bande passante à 1600€/mois.
Il faut changer le mode de fonctionnement du worker pour qu'il ne télécharge plus les mêmes ressources plusieurs fois. Connexe https://github.com/betagouv/mon-entreprise/issues/2228#issuecomment-1200919760
J'ai regardé un peu et on charge tout les js du dossier assets y compris les legacy ce qui est inutile.
Ca divise par 2 le poids téléchargé par la pwa (de 15240.79 KiB à 7507.55 KiB)
J'ai testé plusieurs idées pour réduire le precache de la pwa :
La première était d'avoir des chunks plus petit et découpé par module (un chunk react, publicodes, etc), cela aurais permis de garder en cache les dépendances qui ne change pas souvent. J'avais déjà fait quelque chose de semblable avec Webpack qui possède des options pour faire ce genre d'optimisation. J'ai donc tenté avec Rollup (via manualChunk) mais cela pose problème car Rollup ne garantie pas que le bundle fonctionne si il est découpé manuellement.
La seconde était de ne pas ajouter les chunks lazy import au precache de la pwa, cela réduit bien le poids téléchargé à l'installation mais cela pose problème quand on est offline et que l'on va sur un page lazy loadé, la page crash si on ne l'a pas chargé avant. Pour contourner ca j'ai tenté de plusieurs choses via workbox (fallback un composant react Offline, poster un message du service worker au client pour naviguer vers une autre route...) sans succès. J'ai finalement réussi en passant par un ErrorBoundary, à voir si ca fonctionne bien avec tous les navigateurs.
J'ai aussi externalisé les json dans data qui était inclus dans le build, ca permet de ne pas générer de nouveau chunks tous les jours alors qu'on a fait aucune modification de code.
Je suis arrivé à environ 2900KiB au lieu de 15240KiB pour le precache (sans legacy et sans lazy import), je pense que ca devrais être beaucoup mieux ainsi, je push ca.
Je réouvre car la consommation me parait toujours excessive, nous somme à plus de 300GB depuis le 17 aout, soit environ 60GB/jour. Une option pour résoudre le problème serait de passer par cloudflare comme CDN car il propose une bandwith illimité gratuitement (ex: https://blog.bytefaction.com/posts/save-netlify-bandwidth-using-cloudflare/)
Mettre Cloudfare comme CDN devant Netlify me semble ajouter trop de complexité dans l'infra. Mais si on veut utiliser Cloudflare il y a l’offre "Cloudflare Pages" qui est leur concurrent de Netlify https://pages.cloudflare.com, avec effectivement une bande passante illimité (ainsi qu'un nombre de devs ayant accès au compte illimité).
Mais dans tous les cas ce n'est pas souhaitable que le service worker génère de gros volumes de bande passante. En l’état actuel je suis dubitatif sur son rapport intérêt/coût.
Le problème c'est que je n'arrive pas à comprendre d'où vient cette consommation, depuis le 17 aout on a ~56000 visite sur le site avec une majorité sur la page salarié qui pèse ~1.5MB, normalement on devrait donc être dans les 84GB. Avec nos +300GB on devrait être dans les 200k visite juste du 17 au 22 aout...
Je vois pas trop comment savoir si c'est nos stats qui ne sont pas bonne, ou le calcul de consommation de netlify...
En tout cas il y a un truc qui ne fonctionne pas comme il devrait, on pourrait désactiver la PWA un moment pour voir si ca vient bien de ca, je vois pas trop quoi faire d'autre
Je viens de voir que netlify prend aussi en compte les données qui passe par leur proxy : "- outgoing data sent by your sites in proxied API requests, including requests to Netlify Functions." (source), ca veut dire que l'api augmente aussi le trafic.
Bon à savoir, mais je ne pense pas que ça vienne de là.
J'ai regardé un peu, c'est très mystérieux en effet. Je n'arrive pas à relier les ajouts de Service Worker avec l'augmentation de la bande passante. En tout cas, je ne vois rien d'anormal sur les différentes consoles network des navigateurs (Chrome, Firefox, safari).
Désactiver la PWA est un bon premier pas en effet, histoire d'être sûr qu'on cherche au bon endroit :+1:
C'est quand même fou d'avoir environ 100mb d'utilisation en moyenne à 4h du matin, même en prenant de grosse marge (avec 5mb par visite) ca fait plus de 20 nouveau visiteurs simultané... On doit avoir des bots je vois que ca
Sur scalingo il y a quand même pas mal de requêtes je viens de voir, environ 800 requêtes en continue de 9h à 16h :
Dommage que j'avais pas mon script à ce moment
Pour l'instant il n'y a pas de grosse différence sans la PWA, la barre jaune est le moment du deploy (la courbe était déjà dans la descente avant le deploy)
Pour les navigateurs qui ont déjà la PWA installés, je me demande si le premier retour sur le site n'est pas comme avant, c'est à dire géré par la PWA avant d'avoir un rechargement de la page. C'est l'impression subjective que j'ai eu quand ça m'est arrivé.
Il me semble qu'il force le rechargement de la page une fois qu'il a téléchargé la nouvelle version (sans popup), c'est la seul différence
CR du point de ce matin :
Pour remettre la PWA sur le site :
- stratégie "network first" sur toutes les ressources en particulier la page html initiale
- pas de préfetch pour ne pas consommer des données inutilement chez nos utilisateurs
Possible de configurer une PWA avec prefetch de toute l'appli si la personne choisi d'installer l'application avec l'option système
Les deux premier points sont fait dans #2252 (le precache n'est pas complètement désactivé mais ne télécharge que des fichiers nécessaire)
Le troisième point n'est pas possible actuellement car l'event appinstalled n'est disponible que sur chrome et edge (voir https://caniuse.com/mdn-api_window_appinstalled_event), mais ce n'est pas très important car la majorité des simulateurs fonctionne juste en allant sur la home page
C'est la rentrée aussi :) Plus de traffic aujourd'hui https://explorer.atinternet-solutions.com/core/#/overview/overview/010101?period.shortcut=today&period.end=14:02&period.comp.shortcut=previousPeriod&period.granularity=3&site=617190&graph.options.defaultlist=minmax&graph.options.comparisonlist=comparisonperiod&graph.options.displayoptionlist=classicline&graph.options.eventloglist=eventlog
J'ai fait une estimation grossière et si ca continue comme ca on sera dans les 1.4TB vers la fin du mois netlify (le 17 septembre)
