jQuery Lazy Load pour SPIP

/jQuery-Lazy-Load-pour-SPIP

  • Grosse modif de mon #plugin #SPIP image_responsive : il permet désormais de choisir de charger les images en lazyload
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée, c’est de transformer un des inconvénients de ce système (lancer le chargement des images après un premier rendu de la page) en avantage, et d’intégrer directement un système de lazyload : c’est-à-dire ne charger que les images qui sont réellement affichées dans les limites visibles de l’écran.

    Le plugin change de syntaxe : la deuxième variable permettait de désactiver le chargement des images haute définition, je décide de l’éliminer parce que ça ne sert à rien avec les modifs récentes (calculs et compression plus efficaces), et à la place, la seconde variable permet d’activer (si elle est mise à la valeur « 1 ») le lazyload sur cette image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_proportions{16,9}
            |image_responsive{0,1})
    ]

    Ici, |image_proportions va recadrer l’image selon les proportions 16/9e, sans réduire cependant la taille de l’image.

    Et |image_responsive va fabriquer les éléments permettant le chargement d’une image responsive. Ici, la première variable (« 0 ») est la taille de la vignette chargée par défaut (avec la valeur 0, je décide de ne pas intégrer de vignette : je charge « rien.gif » à la place). La seconde variable (« 1 ») indique donc qu’il ne faut charger cette image que si elle se situe dans la fenêtre visible.

    Au passage, le javascript de lazyload est assez marrant, j’ai privilégié l’efficacité des calculs, du coup la « position » verticale de l’image dans la page est calculé une seule fois (au chargement et au redimensionnement) et stocké dans un « data-top », puis effacé. Ça évite de faire des calculs à chaque fois qu’on scrolle. En revanche, on perd potentiellement en précision (images qui se déplaceraient dans la page, ou blocs affichés/masqués).

    À noter qu’il y a évidemment une tolérance : ça charge un peu plus que l’écran visible, c’est pas la peine que les gens voient trop que les images n’ont pas été chargées.

    Enfin, il y a désormais un calcul en javascript de la hauteur des images tant qu’elles sont en "rien.gif", ça permet de calculer plus précisément le lazyload.

    Comme d’habitude, je l’utilise sur Orient XXI :
    http://orientxxi.info

    • Je me posais la question au sujet du Lazyload, si y’avait pas une autre approche envisageable (c’est peut-être la tienne et j’ai pas compris) :
      – afficher en priorité les images visibles
      – puis aller chercher et « afficher » les autres images (sans attendre que la personne scroll, donc « en-dessous » de la ligne de flottaison)

      J’ai l’impression qu’en terme de rapidité d’affichage c’est équivalent quand on arrive sur le site, mais que cette solution est plus agréable quand on scroll parce qu’on donne une chance pour que les images aient le temps de s’afficher avant (en tous cas forcément plus qu’avec le lazyload).

      C’est peut-être au niveau de la consommation de la bande passante que la solution lazyload est plus avantageuse, mais je ne sais pas quand elle situation elle est vraiment utile.

      Après je dis tout ça un peu comme ça, je sais pas précisément comment ça marche en javascript, peut-être que ce que je propose n’est tout simplement pas possible.

      Une dernière remarque : y’a déjà un plugin LazyLoad dans SPIP.
      http://contrib.spip.net/jQuery-Lazy-Load-pour-SPIP

      Il ne fonctionne pas sur les mêmes principes, mais peut-être pourrait-il être amélioré, en lui donnant des options et tout ? Ou peut-être autonomiser cette fonction si des gens veulent l’utiliser sans le reste du plugin (là encore, tout ça est peut-être trop imbriqué...) ?

      En tous cas merci pour toutes ces contributions autour des images et du #RWD.

    • En gros, ce que fait LazyLoad, c’est de lancer le script jquery Lazy Load, très connu. Mon script est très différent, et son principe de fonctionnement est également très différent, j’ai essayé d’optimiser (limiter les recalculs de positionnement) et ça doit fonctionner en responsive (donc je ne fixe pas les dimensions des images a priori).

      Ensuite, le principe du lazy load n’est pas idéal non plus dans l’absolu (notamment parce qu’il bloque le pré-chargement des images). En tout cas, le fait de charger des images progressivement avant de les afficher, c’est l’assurance de ne pas afficher toutes les images en même temps. Si on a de grosses images, ce n’est pas grave (il y a une image par « écran », plus ou moins), mais si c’est une multitude de petites vignettes (c’est le cas de Flip-Zone), la page est redessinée plusieurs fois (à chaque vignette) et c’est pénible ; en changeant d’un coup toute une série complète de « img src », j’ai bien l’impression que les navigateurs sont optimisés et assez souvent, toute une série de vignettes s’affichent d’un seul coup. Avec un preloading individuel, ça n’a pas l’air de faire pareil (une de mes versions faisait ça : préloading puis affichage). Le preloading avant d’afficher, c’est pas mal sur tout petit écran, mais ça m’a semblé au contraire très pénible sur écran normal.

      Sinon, un preloader de toutes les images, c’est une idée, mais c’est encore un autre principe à mon avis. Je n’y suis pas favorable pour l’instant : charger des trucs « en trop », c’est justement ce qu’il s’agit d’éviter avec les image_responsive (parce qu’on est sans la 3G, parce que le smartphone n’est pas très vaillant…), alors pour le coup, ne charger que si les gens scrollent réellement. Et si tu veux faire ça, à mon avis, le mieux est encore de ne pas utiliser l’option « lazyload » de mon plugin : tu laisses le comportement normal, et je suspecte que c’est plus ou moins le principe de base d’un navigateur a qui on indique tous les « img src » d’une page – il commence par les premiers et/ou les éléments visibles.