Atelier Webperf - Fermé

[Proposals] Criterion N° 101 - Les scripts sont inclus de manière à ne pas interrompre le rendu navigateur.

Déposer un commentaire

  • 07 October 2012 12:23 - Matthieu Larcher Reply

    Cette formulation me semble manquer d'un peu de souplesse. On veut retarder autant que possible le chargement des scripts, mais certains scripts qui modifient l'aspect de la page ont intérêt à être chargés avant le rendu de la page pour éviter un "FLOUC". <br><br>De la même manière qu'il est préconisé de toujours inclure la taille d'une image sur le tag img, une page ne devrait pas se remodeler au gré du chargement des scripts.<br><br>A mon sens, seuls les scripts qui n'ont pas d'incidence sur l'apparence de la page avant interaction avec l'utilisateur doivent être déférés.

  • 29 June 2012 13:57 - Fabrice Bonny (1) Reply

    Est-ce qu'il n'y a pas une confusion entre le but et les moyens ? Dans ce cas {Placer les scripts en fin de body} et {Ne pas utiliser de requêtes synchrones} ne suffisent pas ?

    • 04 July 2012 16:07 - Elie Sloïm (1) Reply

      Bizarre : {Ne pas utiliser de requêtes synchrones} <br><br>{Chaque requête utilisée est asynchrone} ?

      • 10 September 2012 13:31 - Laurent Denis (1) Reply

        <p>
        Je ramène cette BP "en proposition" où le travail peut se poursuivre,
        pour qu'on y voit plus clair dans la liste en cours de discussion.

        </p>

        • 08 October 2012 12:53 - Jean-Pierre Vincent Reply

          Au final, que je comprenne le blocage :&nbsp;<div><br></div><div style="text-align: left;"><ul><li>on n'en fait pas une reco parce qu'elle est très dure à vérifier, comme le soulignait Jérémy ?<br></li><li>ou parce qu'elle parle d'un objectif et non d'un moyen technique ?<br></li></ul><div>pour moi, les techniques évoluant constamment, je préférais parler de l'objectif global (pas de blocage), plutôt que des techniques à mettre en œuvre (defer, async...)</div></div>

  • 11 April 2012 13:27 - Jean-Pierre Vincent (1) Reply

    plus généraliste peut être : "les scripts sont inclus de manière à ne pas bloquer le rendu navigateur"

    • 12 April 2012 07:27 - Laurent Denis (1) Reply

      proposition : {Les scripts sont inclus de manière à ne pas interrompre le rendu navigateur.} Mais du coup, est-ce qu'on ne couvre pas un éventail de solutions techniques beaucoup plus vaste, rendant la BP difficilement vérifiable ? Peut-être faut-il décliner en plusieurs BP ? Ou s'en tenir à un choix de solution moins généraliste ?

      • 12 April 2012 08:06 - Jean-Pierre Vincent (1) Reply

        on peut faire plusieurs BP pour différentes techniques amenant au même résultat ? dans ce cas là on pourrait scinder en {Tous les scripts qui le peuvent sont appelés le plus bas possible dans la page} et en ouvrir un second {Tous les scripts qui le peuvent sont appelés de manière asynchrone}.
        Au passage, l'inclusion de scripts en bas de page bloque tout de même le rendu sur safari iOS, seul l'asynchrone n'est jamais bloquant

        • 13 April 2012 16:08 - Jérémie Patonnier (1) Reply

          La difficulté que je vois a scinder cette BP en plusieurs BP, c'est la difficulté à mesurer la pertinence de chacune d'entre elle. Un script pourrai tout aussi bien bénéficier d'un positionnement en bas de page que d'un chargement asynchrone. Comment déterminé la meilleur option face au 2 BP correspondantes? Si 2 BP son applicable à un même cas, on va passer beaucoup de temps à vérifier la pertinence de toute les autres et à les marquer "invalide" pour rien (sauf si on utilise un moteur d'inférence à la OCAWA, mais ce n'est pas encore le cas avec Opquast ;)

          Je suis plutôt favorable à une BP généraliste, comme celle de JP dans son 1er commentaire, qui permette de décrire le problème à éviter. En creux, un tel BP se mesure en terme de :

          1. Un script bloque-t-il le rendu navigateur, oui ou non?

          Si c'est "non", la BP est validé quelque soit la solution technique

          Si c'est oui, alors se pose une autre question:

          2. Dans le contexte de la page, un solution technique est-elle applicable qui permettent d'évier le blocage du rendu par le script concerné, oui ou non?

          Si c'est oui, alors la BP est invalide

          Si c'est non, la BP est "inapplicable".

          La détermination de la réponse à cette dernière question requiert une très bonne connaissance de ces techniques, mais c'est un exigence normal d'avoir ce genre de connaissance si l'on veux pourvoir mesurer ce genre de BP.

          • 13 April 2012 19:24 - Laurent Denis (1) Reply

            Ok. Je butte un peu sur "bloquer", d'où le "interrompre" ci-dessus. Est-ce pertinent ? Sinon, d'après ce que tu indiques, on s'orienterait alors vers une BP généraliste, mais pas au niveau 1 vu la difficulté d'évaluation...

            • 16 April 2012 08:35 - Jérémie Patonnier (1) Reply

              Oui, on à un gros problème d'évaluation de cette BP car, quelque soit sa formulation, il faut passer *beaucoup* de temps dans le code pour savoir si son chargement avant le chargement de la page est pertinent ou non. Les bonnes pratiques en matière de gestion des scripts évoluent vite en ce moment (defer vs. Lazy Loading vs. Instant loading, etc.) et restent très conditionnées à un contexte de mise en œuvre.

              • 17 April 2012 16:42 - Laurent Denis (1) Reply

                Pour le moment, sauf avis génial inopiné, on resterait sur la reformulation {Les scripts sont inclus de manière à ne pas interrompre le rendu navigateur} au niveau 3 cette fois ?

                • 18 April 2012 12:14 - Jean-Pierre Vincent (2) Reply

                  la formulation me semble bonne, en tout cas elle me parle, mais du coup c'est du niveau 1 en terme d'impact sauf si il y en a une ou plusieurs autres plus précises