Optimisation du chargement de page web

29 juillet 2019 à 11:07:52

Bonjour,

Dans le cadre de mon boulot, je réalise un module de saisi pour des inventaires de "points" d'éclairage public.

Dans les grandes lignes, ce module se compose des fonctions suivantes :

- un affichage carto web des points, avec possibilité d'upload d'un CSV dont le contenu s'affichera sur la carto.

- au minimum 6 tableaux contenant les informations du CSV, suivant la nature du point (luminaire, ..) et l'action (nouveau, remplacement, ..)

- chaque tableau se compose de 28 à 53 colonnes, et pourra accueillir potentiellement un peu plus de 3000 lignes.

- les cellules des tableaux comporte également des inputs/select ... sur lesquelles j'applique un event onchange pour enregistrer la valeur en XHR dans ma BDD à chaque modification.

- beaucoup de mes fonctions font appel au XHR pour éviter un rechargement de la page.

Mon soucis : le temps de chargement de la page est d'environ 12s. pour seulement 350 lignes dans mes tableaux. (je n'imagine donc même pas lorsqu'il y aura + de 1000 lignes ...)

J'essaie de trouver des solutions pour optimiser ce chargement mais ce que j'ai déjà testé n'est pas très significatif :

- passer les scripts JS en fin de page

- épurer le CSS et le JS de mise en forme purement esthétique (ombre, slide ...)

- optimiser l'affichage de mes lignes (affichage direct plutôt que l'utilisation d'une fonction JS qui "redispatche" les lignes dans les bons tableaux.

Il y a t-il d'autre solutions possibles ? ou dois-je de toute façon m'attendre à un tps de chargement long à cause du nombre de lignes à afficher ?

Merci d'avance

Anonyme

29 juillet 2019 à 11:23:14

À moins que tu affiches des images de plusieurs Mo c'est probablement le code serveur qui est responsable d'une telle attente ? D'où sortent les 12 secondes ?

tabouretBleu

29 juillet 2019 à 12:58:16

Il faut que tu fasses un audit de la page. Tu risques de passer du temps à optimiser des trucs qui n'ont pas d'impact sur le chargement. Ouvre tes outils de développement et regarde ce qui se passe dans la partie Network puis Performance (il faudra peut-être activer cette dernière dans les options)

ElodieMary

29 juillet 2019 à 14:13:12

MatTheCat-> les 12s viennent de l'analyse de Firefox, dans les outils de dev' (12s quand je travaillais en VPN et 6s quand je travaille depuis mon poste au boulot).

tabouretBleu -> je me base justement sur l'onglet reseau pour voir un peu. Voilà ce qu'il peut me sortir :

-
Edité par ElodieMary 29 juillet 2019 à 14:14:55

Anonyme

29 juillet 2019 à 14:24:40

Alors déjà un document HTML de 6,41Mo c'est un problème. Non seulement il n'y a aucune compression mais c'est tellement énorme que ça cache sans doute quelque chose.

Ensuite jQuery n'est plus utile aujourd'hui donc on peut gagner beaucoup à le virer.

Créer la carte après que le DOM est chargé pourrait aider aussi.

ElodieMary

29 juillet 2019 à 14:59:06

Merci pour ta réponse !

Effectivement je n'avais pas fait gaffe au 6,41 Mo de doc HTML !

Après c'est surement dû à mes tableaux que je génère avec ma BDD et je ne peux pas toucher à ça. (ou alors il faut que je réduise au maximum les éléments à afficher).

Pour JQuery, je ne peux pas le virer car j'en ai besoin pour afficher ma carte avec Leaflet (sauf si tu as une solution pour de la carto web sans Jquery auquel cas je suis preneuse !).

Techniquement, la carte se charge en dernier, j'ai mis tous les scripts juste avant le </body>

Anonyme

29 juillet 2019 à 15:10:45

Ça m'étonnerait que tu puisses faire tenir 6Mo de données dans une page lisible ; à mon avis seule une fraction de ces données est affichée, auquel cas il serait plus performant que seule cette fraction soit présente dans la page.

Je vois mal comment jQuery pourrait être une dépendance de leaflet ? S'il s'agît uniquement d'une méconnaissance de JavaScript il serait temps de passer le cap ! https://putaindecode.io/articles/de-jquery-a-vanillajs/

Sinon le navigateur n'a pas fini de charger le DOM avant la fermeture de <body> donc il suffit que le JavaScript soit synchrone pour que DOMContentLoaded soit repoussé.

ElodieMary

29 juillet 2019 à 15:55:08

MatTheCat a écrit:

Ça m'étonnerait que tu puisses faire tenir 6Mo de données dans une page lisible ; à mon avis seule une fraction de ces données est affichée, auquel cas il serait plus performant que seule cette fraction soit présente dans la page.

-> Effectivement, il y a des éléments que je masque mais qui sont quand même présent dans le DOM. J'avais fait cela comme ça car une des fonctions présentes est de pouvoir déplacer une ligne dans un autre tableau en fonction d'un choix dans un select. Est-ce plus rapide de fait un XHR pour récupérer une ligne plutôt que de simplement modifier le display ?

MatTheCat a écrit:

Autant pour moi pour ce point, vu que je n'ai pas mis en place moi même cette carto web, j'étais persuadé que Leaflet utilisait JQuery ... Bon une bonne partie de mon code est en Vanilla JS, donc je transformerais le restant qui est encore en JQuery. Merci pour la source.

MatTheCat a écrit:

Sinon le navigateur n'a pas fini de charger le DOM avant la fermeture de <body> donc il suffit que le JavaScript soit synchrone pour que DOMContentLoaded soit repoussé.

Il faut que j'utilise l'attribut async sur mes balises script du coup ?

Merci pour ton temps et tes réponses !

Anonyme

29 juillet 2019 à 16:21:40

Comme tu le mentionnes tu auras beaucoup plus de données dans le futur. Si le parsing souffre déjà autant je pense que tu vas être obligée de passer par du lazy loading.

Concernant les scripts je pense que c'est de l'attribut defer dont tu as besoin : ils seront téléchargés en parallèle du parsing HTML et exécutés dans l'ordre une fois que le DOM sera construit. Nul besoin de les placer à un quelconque endroit de ton HTML du coup.

tabouretBleu

30 juillet 2019 à 20:43:20

Ton HTML est téléchargé en 0.5 secondes et parsé en... 6.85 secondes. Le truc à optimiser c'est ça et pas autre chose. 6.4Mo pour seulement 350 lignes ça va pas.

Personnellement j'enverrais le CSV en entier au navigateur, que ce soit en une fois s'il n'est pas trop lourd, ou par morceaux, en arrière-plan, et je générerais le HTML en Javascript à la demande avec un système de pagination et de filtres. Maintenant, ce n'est pas ton architecture actuelle donc ça représente pas mal de boulot.

Je suis surpris que tu ne nous parles pas de latence à l'exécution. Parce qu'une page aussi lourde ça devrait faire ramer le navigateur à l'usage (barre de défilement, redimensionnements, changement de display des lignes ou colonnes...). Je testerais d'envoyer des tableaux de 3000 lignes et de voir comment ça se comporte avant de prendre une décision. Si c'est pas trop lent, il suffirait d'envoyer le HTML par morceaux en affichant le premier morceau tout de suite.

ElodieMary

15 août 2019 à 17:13:56

Désolée du retard de réponse de ma part (entre les vacances et d'autres projets, celui-ci reste en stand-by ...)

En tout cas merci pour vos pistes de solution, j'en discute avec mon responsable mais la solution de n'afficher qu'une partie des lignes et de n'afficher la suite qu'à la demande me semble un une bonne piste !

tabouretBleu a écrit:

Je suis surpris que tu ne nous parles pas de latence à l'exécution. Parce qu'une page aussi lourde ça devrait faire ramer le navigateur à l'usage (barre de défilement, redimensionnements, changement de display des lignes ou colonnes...). Je testerais d'envoyer des tableaux de 3000 lignes et de voir comment ça se comporte avant de prendre une décision. Si c'est pas trop lent, il suffirait d'envoyer le HTML par morceaux en affichant le premier morceau tout de suite.

Je n'en ai pas parlé car il reste disons "supportable" mais on en ressent les effets .. Le test des 3000 lignes est prévu également.

Je vous tiens au courant, et merci encore !