Hacer que los sitios web receptivos funcionen
Hubo un tiempo en el que podías diferenciar con confianza entre una página web de escritorio y una página web móvil. Tanto es así, de hecho, que toda una industria creció en torno a la reutilización de sitios de escritorio para dispositivos móviles.
Por un tiempo, no eras nadie si no tenías un sitio móvil separado en un dominio separado. Entonces las cosas empezaron a cambiar.
Las pantallas móviles mejoraron más allá de todo reconocimiento. También lo hicieron los navegadores móviles. Las tabletas arrojaron otro elemento a la ecuación. Llegó el 4G. Las pantallas Retina ofrecieron nuevos niveles de claridad para los usuarios finales.
De repente, la línea entre el escritorio y el móvil se veía borrosa.
Al mismo tiempo, hubo una creciente diversidad en el tamaño y la resolución de las pantallas de escritorio.
Y un dolor de cabeza creciente para los diseñadores web.
Atrás quedaron los días en los que solo tenía que atender a un puñado de tamaños de ventana gráfica. Las cosas se estaban complicando.
Afortunadamente, la ayuda estaba disponible en forma de consultas de los medios y el concepto de diseño receptivo.
Gracias a las consultas de medios, fue posible variar los estilos y el diseño, incluso el contenido, según el ancho de la ventana gráfica y la resolución de la pantalla del usuario. Por supuesto, las consultas de medios no son de ninguna manera la única herramienta en la bolsa de trucos del diseñador receptivo, pero es justo decir que forman la base de la técnica.
Esta fue una gran noticia para los dispositivos móviles. El diseño receptivo significaba que podía entregar de manera efectiva diferentes versiones del mismo sitio a diferentes dispositivos. Todo sin desarrollar un sitio móvil separado en un dominio diferente.
¿Qué pasa con el rendimiento?
Los propietarios de sitios comienzan a darse cuenta de que los usuarios finales se preocupan por el rendimiento. Los minoristas en particular están comenzando a apreciar que reducir milisegundos de tiempo de carga puede traducirse en millones en el balance general.
Afortunadamente, los sitios receptivos ofrecen un claro beneficio de rendimiento sobre sus primos móviles dedicados: se elimina la redirección a un dominio móvil.
Sin embargo, a pesar de esto, el diseño receptivo ha logrado adquirir cierta reputación por su bajo rendimiento.
En cierto modo, esto es bastante injusto, pero vale la pena considerar los desafíos adicionales de rendimiento que el diseño receptivo genera en los desprevenidos…
Imágenes
Los archivos de imagen son grandes. Y debido a que son grandes, a menudo son los culpables de los tiempos de carga lentos. Por lo tanto, son un buen punto de partida para cualquiera que intente optimizar el rendimiento de un sitio.
Desafortunadamente, una de las primeras soluciones para entregar imágenes de manera receptiva no fue excelente para el rendimiento.
La técnica es maravillosamente simple. Simplemente use max-width: 100% para asegurarse de que las imágenes se escalen al ancho del elemento que las contiene:
img
{
max-width: 100%;
}A medida que el contenedor se encoge para adaptarse a ventanas de visualización más pequeñas, cualquier imagen del interior se encogerá con él. ¡Fácil!
Pero hay un problema. El tamaño de la imagen puede reducirse en la pantalla, pero el tamaño del archivo sigue siendo el mismo. Esto está lejos de ser ideal desde el punto de vista del rendimiento. Podría estar enviando una imagen de 800 x 800 píxeles por el cable, solo para que se muestre a 80 x 80 píxeles: en otras palabras, podría estar transmitiendo cientos (o miles) de bytes innecesarios. No solo la imagen tardará mucho en cargarse, sino que todos esos bytes redundantes podrían estar agotando la valiosa asignación de datos del usuario final.
Sin embargo, esta no es la única, ni siquiera la mejor, forma de ofrecer imágenes receptivas. Por un lado, una imagen que funciona a 800 píxeles de ancho no necesariamente funcionará tan bien en varias fracciones de ese tamaño.
Para lidiar con esto, puede usar una consulta de medios para mostrar diferentes versiones de la imagen dependiendo del tamaño de la ventana gráfica usando una consulta de medios y mostrar: ninguno.
CSS:
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML:
![]()
![]()
Esto le permite mostrar diferentes versiones de una imagen, en lugar de solo la misma imagen en diferentes tamaños. Sin embargo, no reduce el número de bytes. De hecho, el tamaño total de la página será mayor, ya que se cargarán todas las imágenes, se muestren o no.
Una mejor alternativa, si es práctica, es usar imágenes de fondo en lugar de
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Esto funciona bien: los visitantes descargan solo las imágenes que necesitan, cuando las necesitan. El problema es que es desordenado y trata efectivamente el contenido como estilo. Como tal, potencialmente crea un problema de mantenimiento y también podría resultar en que los motores de búsqueda ignoren imágenes importantes.
En su lugar, ¿por qué no usar SVG (gráficos vectoriales escalables): un formato de imagen que escala por su propia naturaleza? Las imágenes SVG también tienen la ventaja de que se pueden diseñar fácilmente con CSS (consulte este excelente tutorial sobre cómo hacer que los SVG respondan con CSS). Esto es perfecto para íconos y logotipos, pero desafortunadamente, no podrá usar SVG para fotos; para esto, tendrá que recurrir a formatos rasterizados, como JPEG.
Otra opción es usar una de varias soluciones de JavaScript para entregar imágenes receptivas. Esta es una forma popular de hacerlo, pero agrega otra capa de complejidad. Además, dado que JavaScript bloquea la construcción de DOM, cualquier solución que involucre JavaScript tiene el potencial de retrasar el procesamiento. Entonces, si bien existen algunos complementos muy inteligentes, con solo introducir JavaScript en la ecuación, hasta cierto punto, se está resignando al menor de los dos males.
Hasta hace poco, estas eran las únicas opciones.
Ahora, sin embargo, los elementos y
En este nuevo y valiente mundo, puede usar srcset para establecer una lista de imágenes candidatas para que el navegador elija. Luego puede usar una consulta de medios en el atributo de tamaños para dictar el tamaño en el que se mostrará la imagen. Usando el elemento junto con las consultas de medios dentro de uno o más elementos, puede especificar un rango diferente de imágenes para diferentes condiciones (por ejemplo, para ventanas gráficas de hasta un cierto ancho, use la imagen a, b o c, y para ventanas gráficas más grandes use la imagen x, y o z). Esto es útil si necesita entregar una versión recortada de una imagen para usuarios con pantallas pequeñas.
El detalle preciso de cómo usar la nueva sintaxis está fuera del alcance de este artículo, pero puede encontrar un excelente tutorial en alistapart.
Quizás la única desventaja de esta nueva especificación es que es bastante larga, lo que podría significar HTML inflado en páginas con muchas imágenes. Sin embargo, los beneficios superan con creces los inconvenientes.
Cargando CSS que no necesita (necesariamente)
Aunque las consultas de medios le permiten aplicar diferentes reglas de CSS según los criterios que haya establecido, no se puede evitar el hecho de que los usuarios finales tendrán que descargar todo el CSS que pueda aplicarse. Esto es cierto incluso si coloca su CSS en archivos separados y coloca su consulta de medios en el
elemento.Por ejemplo, se cargarán las dos hojas de estilo siguientes, independientemente del ancho de la ventana gráfica:
Esto no es un error del navegador. Los criterios utilizados en las consultas de medios a menudo se relacionan con cosas que cambian durante una visita a una página. Por ejemplo, un visitante puede decidir cambiar el tamaño de la ventana del navegador o rotar su tableta/dispositivo móvil. El cambio resultante en la visualización debería ser perfecto, y enviar una solicitud de otro archivo CSS estaría lejos de ser ideal. Esto es especialmente cierto para los dispositivos móviles, que buscan cerrar los enlaces de radio lo antes posible para conservar la energía de la batería. Potencialmente, tener que restablecer ese enlace cuando cambia el tamaño de la ventana gráfica podría ser una mala noticia para la duración de la batería.
Sin embargo, Chrome se esfuerza por tratar estos diferentes archivos de forma inteligente. Si bien se descargarán todos los archivos, solo el que tenga la consulta de medios coincidente actualmente bloqueará la representación. Cualquier otro se cargará con menor prioridad.
Desafortunadamente, otros navegadores no son tan útiles. En Firefox, por ejemplo, los archivos CSS no utilizados no solo bloquean la representación, sino que también bloquean la carga de otros objetos en la página.
El siguiente gráfico de cascada ilustra el punto. Las imágenes de esta página no comienzan a cargarse hasta que el archivo CSS no utilizado se haya descargado por completo:
Puede evitar esto usando JavaScript para cargar CSS condicionalmente pero, como ya hemos visto, JavaScript tiene sus propios costos de rendimiento.
¿Qué significa todo esto para el rendimiento de un sitio receptivo frente a un sitio móvil?
Bueno, los usuarios de dispositivos móviles y de escritorio en un sitio receptivo tendrán que descargar el mismo CSS.
Y habrá más de lo que habría en un sitio diseñado solo para computadoras de escritorio o dispositivos móviles.
Además, es más probable que un sitio móvil dedicado use una versión más ligera y simplificada del CSS de escritorio (aunque esto quizás sea menos cierto ahora, ya que los usuarios esperan una experiencia más rica en pantallas móviles cada vez más sofisticadas).
Entonces, en igualdad de condiciones, parece que hay algo en el argumento de que es probable que un sitio responsivo sea más lento que un sitio móvil debido al CSS adicional requerido. Sin embargo, siempre que los diseñadores sean conscientes de los peligros potenciales, deberían poder crear hojas de estilo de carga rápida para un sitio receptivo. En particular, es una buena idea:
-
evite usar URI de datos para imágenes: las imágenes de fondo binarias (normalmente) se cargarán solo si son necesarias, pero todos los URI de datos se cargarán independientemente. -
manténgalo liviano: dado que todo el CSS debe descargarse, es importante ser eficiente. Esto significa evitar la duplicación y asegurarse de que las reglas globales se establezcan fuera del CSS basado en consultas de medios.
RESS (Diseño web receptivo + Componentes del lado del servidor)
RESS es un híbrido entre diseño receptivo y adaptativo, lo que implica que el agente de usuario olfatee el servidor para ver las características del dispositivo del cliente y entregar contenido apropiado para él.
Si una de las objeciones al diseño receptivo es que implica entregar todo el contenido a todos los dispositivos, ¿por qué no mitigar esto eliminando parte de ese contenido donde pueda?
Esto puede tener mucho sentido. Si hay una imagen que sabe que nunca querrá mostrar en dispositivos cuya pantalla está por debajo de cierto tamaño, es mejor que no la envíe a esos dispositivos, ahorrando ancho de banda y reduciendo el tiempo de carga.
Además, si está utilizando consultas de medios que sabe que no se pueden satisfacer en ciertos dispositivos, existe al menos un argumento para separar su CSS en diferentes archivos y cargarlos condicionalmente.
Vale la pena tener en cuenta que todo este proceso no es 'gratis' en términos de rendimiento. Obviamente, se debe realizar algo de trabajo en el servidor, lo que lleva tiempo, probablemente no lo suficiente como para compensar los beneficios, pero es algo a tener en cuenta.
El veredicto
¿Los sitios responsivos son lentos?
Depende de lo que entiendas por lento.
¿Es probable que el sitio de respuesta más rápida que pueda crear sea más lento que el sitio móvil dedicado más rápido que pueda crear?
Probablemente.
También hemos visto que hay algunas trampas. Si no tiene cuidado, es fácil terminar obligando a los usuarios a descargar muchas imágenes redundantes y CSS, lo que hace que su sitio receptivo sea mucho más lento de lo que debe ser.
Sin embargo, no tiene por qué ser así. Es perfectamente posible crear un sitio receptivo que sea tan rápido como debe ser y brinde una excelente experiencia de usuario. Y a medida que tanto los estándares como los navegadores comiencen a ponerse al día con lo que los desarrolladores quieren ofrecer, debería comenzar a ser más fácil.
Fuente de grabación: instantshift.com