soy Kseso y esto EsCSS

Comparativa galería imágenes deslizantes: jQuery frente a Css

Comparativa de una galería de imágenes deslizante realizada con un plugin de jQuery o en puro Css.

Comparativa galería imágenes deslizantes: jQuery frente a Css

·Por Kseso ✎ 3
imagen de la galería de paneles deslizantes

Hace unas fechas, @Oloman publicaba en su gran blog un interesante artículo (como todos los demás) para realizar una galería de imágenes deslizantes basada en un plugin de jQuery. Decía en su introducción:

@Oloman autor de OlobloggerEsta librería que funciona con jQuery es muy resultona para sitios que necesiten mostrar imágenes en un espacio reducido.
Se llama Kwicks y facilita la conversión de una lista en paneles deslizantes que dejan mostrar sólo una porción de su contenido hasta que se hace hover sobre alguno, momento en el que suavemente se amplía su ancho para que se vea con la medida que previamente hemos indicado.

Y aquí es donde te remito otra vez (y recalco la obligatoriedad) de que pases por su artículo donde tienes toda la información, incluidos enlaces y una demo.

Y uno, que como soy un enredique y además no tengo ni idea de js y sus librerías, pensó si no sería un tanto excesivo recurrir a todo lo que necesita para su funcionamiento.

Aclaración previa:

No veas este artículo como una desautorización o ataque al de Oloman. Sería, como poco, una necedad por mi parte si así lo enfocase.
Es todo lo contrario: es complementario y sólo pretendo ofrecerte una segunda forma de hacer lo mismo y que tengas datos para escoger con un poco de información.

Lo mismo en Css

Para poder hacer una comparativa mínima, lo primero sería tener la misma realización en Css. Así que ayudándome en un viejo post de este blog que recrea el mismo efecto. El fork en puro Css: a página completa [original en jsfiddle]. A continuación su pen:

See the Pen VvQGXG by Kseso (@Kseso) on CodePen.

Ver Demo a Full

Nota del Editor: ambas galerías son realizaciones de 2012, así que temas como el rwd, medidas en relación al viewport o la función calc() de css como que eran cuestiones secundarias. Cuestiones que no afectan a la comparativa.

Los recursos

Como puedes ver, el funcionamiento y la apariencia es la misma. Excepto el pequeño detalle del espacio de separación entre imágenes que he suprimido por creerlo innecesario y sobrante: se trata de aprovechar el espacio lo mejor posible.

Versión js: Recursos y tráfico

peso de los jsLa realizada en base a jQuery vemos que necesita de 2 scripts, que son dos peticiones al servidor, con un peso total de 99KB.

Así mismo, el css asociado suponen otros 903bytes.

Sin entrar en consideraciones de si se podría o no optimizar, en total son 3 peticiones al servidor y un peso total de ~100KB. No es mucho en estos días. Pero es.

versión Css: Recursos y tráfico

En la versión en puro Css sólo necesitamos 1 petición a los estilos. Total: 966bytes ~ 1KB incluyendo los prefijos privativos en la propiedad transition.

El inspector

Si echamos un vistazo a los datos del inspector de Chrome mientras interactuamos con la galería haciendo :hover hay un par de detalles que llaman la atención:

inspector de Css
La versión con Css
inspector js
La versión con Js

Y si utilizas el analizador de Opera (dragon fly) vemos que en esta realización al igual que en el estudio de Animaciones ¿Css3 o jQuery? tanto la memoria consumida como las acciones (reflow, repintado del layout, reclacular los estilos) es mayor en la versión basada en javascrit frente a la del puro Css.

El cómo trabajan marca la diferencia

Las diferencias están en cómo hace la versión en js. Fíjate en las siguientes capturas.

Cuando la galería no ha recibido aún el :hover cada item de la lista tiene aplicados en línea unos estilos (vía js): valor de left y tamaño.

reflow y repaint 1

Al interactuar con el primer item, el script entra en funcionamiento. Tiene que aplicar una clase a ese li que recibe el :hover, aumentando su tamaño, lo que le obliga a recalcular el resto (reduciendolos) y variando tanto el tamaño como el valor de posicionamiento:

reflow y repaint 2

Y esto mismo cada vez que movemos el cursor de uno a otro li

reflow y repaint 3 reflow y repaint 4

Este constante reflow de los estilos y repintado del layout es el responsable de la carga y recursos consumidos, ya que en la versión css se reduce el tamaño de todos los li al recibir la lista el :hover aumentando el tamaño del item que conjuntamente a lo anterior tiene el cursor encima. No hay ninguna clase que se añada/retire y recalcular posiciones y tamaños de todos en cada acción.

Todo lo anterior lo puedes ver mucho mejor en las 2 siguientes capturas del inspector de Opera (Dragonfly). Fíjate en lo que ocurre y en los valores de la izquierda al interactuar con la versión de js:

JS: reflow y repaint en opera dragonfly

Y la más absoluta calma en la galería con Css:

CSS: reflow y repaint en opera dragonfly

Conclusiones

Sólo una: nada es mejor o peor en términos absolutos. Todo depende de cada caso. Y frente a los datos siempre prevalecen las habilidades, conocimientos y sentirse a gusto de cada cual.

Y siempre es mejor poder elegir entre más de una opción que el verse obligado a hacer todo todos de la misma forma.

N.B.: Una pequeña aclaración: me he callado, al hablar de peticiones y peso, una posible circunstancia muy común: que por lo extendido que está (casi es práctica general) cargar las librerías js (jQuery en este caso) para cualquier cosa, es rara la página que no la tiene ya incluida en su código.

Artículo publicado originalmente en Diciembre de 2012.

avatar del Editor del blog

the obCSServer ᛯ Ramajero Argonauta, Enredique Amanuense de CSS.
#impoCSSible inside
Dicen que, en español, EsCss es el mejor blog de CSS. Posíblemente exageren.
@Kseso EsCss Kseso