Atelier Webperf - Fermé

[Proposals] Criterion N° 108 - Seule la prévisualisation d'une vidéo est pré-chargée au chargement de la page.

Déposer un commentaire

  • 10 September 2012 13:43 - 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>

  • 13 April 2012 17:15 - Jérémie Patonnier (1) Reply

    Proposition de reformulation: {Seule la prévisualisation d'une vidéo est pré-chargée pendant le chargement de la page}

    • 04 May 2012 16:51 - Fabrice Bonny (1) Reply

      {Seule la prévisualisation d'une vidéo est pré-chargée} :)

      • 09 May 2012 09:36 - Jean-Pierre Vincent (1) Reply

        je serais d'avis de garder la précision sur le chargement de la page, qui est un moment critique. Par exemple certaines vidéos se lance dans une popin / layer après avoir cliqué sur un lien, là il ne me semble pas dérangeant de directement lire donc charger la vidéo car c'est une demande de l'utilisateur

        • 29 June 2012 15:14 - Fabrice Bonny (1) Reply

          Si on lance la vidéo, on est plus dans le contexte d'une prévisualisation, non ? On pourrait faire {Une vidéo en streaming n'est pas préchargée avant son lancement}, voire {Une ressource en streaming n'est pas préchargée avant son lancement}.

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

            {Le pré-chargement d'une vidéo se limite à son image de prévisualisation}

            • 05 July 2012 10:10 - Jérémie Patonnier (1) Reply

              Non, cette formulation ne va pas car elle est trop radical en éliminant la notion de moment ou elle est necessaire. Le problème du chargement des ressources en général et des vidéos en particulier et un problème de gestion des capacités du réseau (le plus souvent inconnus et de toute façon variable) mise en regards de la réactivité de l'interface en fonction des actions de l'utilisateur. L'objectif est de faire dire à l'utilisateur "ça va vite" (ou au moins éviter qu'il dise "c'est lent").<br><br>Pour arriver à concilier ces 2 problématiques (capacité du réseau / réactivité de l'interface), il faut considérer les points suivant :<br><ol><li>Le chargement d'une ressource doit toujours être asynchrone (sont chargement ne doit jamais bloquer le rendu ni les fonctionnalité de la page)</li><li>Avant la fin du chargement de la page, tout ce qui permet de réduire l’empreinte réseau et accélérer l'affichage doit être priorisé. Dans ce cas, si une zone vidéo est affiché, seul une image de prévisualisation devrait être chargé</li><li>Après la fin du chargement de la page, les vidéo devrais être chargé en tache de fond (idéalement avec un système de priorisation des flux en fonction des actions utilisateurs) pour que dès qu'il demande la lecture d'une vidéo celle-ci commence. Le gros problème du streaming, c'est qu'aujourd'hui, les vidéos embarquées via HTML5 ne supportent pas nativement le streaming (il y a des discussion sur le sujet, mais rien n'est standardisé sur ce point et pas grand chose n'est implémenté). Accessoirement, peu de gens savent faire la différence entre un vrai streaming et un démarrage de lecture alors que le fichier vidéo est en cours de chargement. Exiger du streaming dans une BP c'est fortement contraindre la solution technique, ce qui n'est ni nécessaire ni acceptable dans tous les cas.<br></li></ol><p>Dans le cadre de cette bonne pratique, on essaye de résoudre le point 2. Pour cela, je reformulerai la BP de la manière suivante : {Le pré-chargement d'une vidéo, avant la fin du chargement de la page, se limite à son image de prévisualisation}<br></p>

              • 12 July 2012 12:01 - Elie Sloïm (1) Reply

                1 {Toutes les ressources sont chargées de manière asynchrone}<br>2 {si une zone vidéo est affiché, seule une image de prévisualisation est pré-chargée}<br><br>

                • 12 July 2012 16:04 - Jérémie Patonnier (2) Reply

                  Ouais, ça me plais bien ça... faut voir ce qu'en dise les autres ;)

                  • 13 July 2012 14:09 - Fabrice Bonny Reply

                    Je suis pour les 2 BP. On précisera dans la fiche du point 1 que certaines limitations peuvent apparaître (comme le cas de fichiers JS).

                  • 13 July 2012 09:28 - Laurent Denis (1) Reply

                    Quand je lis {Toutes les ressources sont chargées de manière asynchrone}, j'ai peur pour beaucoup de sites où la question ne se pose même pas.<br><br>Mais sinon, oui.

                    • 13 July 2012 09:42 - Jérémie Patonnier (1) Reply

                      A voir ce qu'en pense des gens un peu plus doué que moi sur la question, mais à ma connaissance les seuls ressources qui sont chargé de manière réellement synchrone sur une page, ce sont les script JS (ils bloquent totalement le rendu de la page tant qu'ils ne sont pas intégralement chargé). Les autres ressources (images, CSS, vidéos, etc.) sont chargé de manière asynchrone et plus ou moins en parallèle leur seul impact et sur le volume de bande passante consommé (ce qui peut ralentir le site, d’où mon point 3 sur la priorisation des ressources ci-avant), mais là on change de BP ;)

                      • 08 October 2012 14:15 - Jean-Pierre Vincent Reply

                        Pour FF et Chrome, JS ne bloque plus les autres téléchargements, mais uniquement le rendu.<div>En fait j'ai un peu de mal avec cette proposition qui concerne uniquement la vidéo :</div><div>- sur des pages où le but est de lire la vidéo, c'est normal de commencer à charger et jouer la vidéo ASAP</div><div>- sur les autres pages, ça n'est effectivement pas souhaitable de prendre toute la bande passante pour pré-charger une vidéo qui ne sera potentiellement pas jouée</div><div><br></div><div>à partir de là, l'intention de la page n'étant pas vérifiable, autant faire sauter cette propale non ?</div>