\n Hubo un tiempo en el que pod\u00edas diferenciar con confianza entre una p\u00e1gina web de escritorio y una p\u00e1gina web m\u00f3vil. Tanto es as\u00ed, de hecho, que toda una industria creci\u00f3 en torno a la reutilizaci\u00f3n de sitios de escritorio para dispositivos m\u00f3viles.\n<\/p>\n
\n Por un tiempo, no eras nadie si no ten\u00edas un sitio m\u00f3vil separado en un dominio separado. Entonces las cosas empezaron a cambiar.\n<\/p>\n
\n Las pantallas m\u00f3viles mejoraron m\u00e1s all\u00e1 de todo reconocimiento. Tambi\u00e9n lo hicieron los navegadores m\u00f3viles. Las tabletas arrojaron otro elemento a la ecuaci\u00f3n. Lleg\u00f3 el 4G. Las pantallas Retina ofrecieron nuevos niveles de claridad para los usuarios finales.\n<\/p>\n
\n De repente, la l\u00ednea entre el escritorio y el m\u00f3vil se ve\u00eda borrosa.\n<\/p>\n
\n Al mismo tiempo, hubo una creciente diversidad en el tama\u00f1o y la resoluci\u00f3n de las pantallas de escritorio.\n<\/p>\n
\n Y un dolor de cabeza creciente para los dise\u00f1adores web.\n<\/p>\n
\n Atr\u00e1s quedaron los d\u00edas en los que solo ten\u00eda que atender a un pu\u00f1ado de tama\u00f1os de ventana gr\u00e1fica. Las cosas se estaban complicando.\n<\/p>\n
\n Afortunadamente, la ayuda estaba disponible en forma de consultas de los medios y el concepto de dise\u00f1o receptivo.\n<\/p>\n
\n Gracias a las consultas de medios, fue posible variar los estilos y el dise\u00f1o, incluso el contenido, seg\u00fan el ancho de la ventana gr\u00e1fica y la resoluci\u00f3n de la pantalla del usuario. Por supuesto, las consultas de medios no son de ninguna manera la \u00fanica herramienta en la bolsa de trucos del dise\u00f1ador receptivo, pero es justo decir que forman la base de la t\u00e9cnica.\n<\/p>\n
\n Esta fue una gran noticia para los dispositivos m\u00f3viles. El dise\u00f1o receptivo significaba que pod\u00eda entregar de manera efectiva diferentes versiones del mismo sitio a diferentes dispositivos. Todo sin desarrollar un sitio m\u00f3vil separado en un dominio diferente.\n<\/p>\n
\n Los propietarios de sitios comienzan a darse cuenta de que los usuarios finales se preocupan por el rendimiento. Los minoristas en particular est\u00e1n comenzando a apreciar que reducir milisegundos de tiempo de carga puede traducirse en millones en el balance general.\n<\/p>\n
\n Afortunadamente, los sitios receptivos ofrecen un claro beneficio de rendimiento sobre sus primos m\u00f3viles dedicados: se elimina la redirecci\u00f3n a un dominio m\u00f3vil.\n<\/p>\n
\n Sin embargo, a pesar de esto, el dise\u00f1o receptivo ha logrado adquirir cierta reputaci\u00f3n por su bajo rendimiento.\n<\/p>\n
\n En cierto modo, esto es bastante injusto, pero vale la pena considerar los desaf\u00edos adicionales de rendimiento que el dise\u00f1o receptivo genera en los desprevenidos…\n<\/p>\n
\n 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.\n<\/p>\n
\n Desafortunadamente, una de las primeras soluciones para entregar im\u00e1genes de manera receptiva no fue excelente para el rendimiento.\n<\/p>\n
\n La t\u00e9cnica es maravillosamente simple. Simplemente use max-width: 100% para asegurarse de que las im\u00e1genes se escalen al ancho del elemento que las contiene:\n<\/p>\n
img\n{\nmax-width: 100%;\n}<\/code><\/pre>\n\n A medida que el contenedor se encoge para adaptarse a ventanas de visualizaci\u00f3n m\u00e1s peque\u00f1as, cualquier imagen del interior se encoger\u00e1 con \u00e9l. \u00a1F\u00e1cil!\n<\/p>\n
\n Pero hay un problema. El tama\u00f1o de la imagen puede reducirse en la pantalla, pero el tama\u00f1o del archivo sigue siendo el mismo. Esto est\u00e1 lejos de ser ideal desde el punto de vista del rendimiento. Podr\u00eda estar enviando una imagen de 800 x 800 p\u00edxeles por el cable, solo para que se muestre a 80 x 80 p\u00edxeles: en otras palabras, podr\u00eda estar transmitiendo cientos (o miles) de bytes innecesarios. No solo la imagen tardar\u00e1 mucho en cargarse, sino que todos esos bytes redundantes podr\u00edan estar agotando la valiosa asignaci\u00f3n de datos del usuario final.\n<\/p>\n
\n Sin embargo, esta no es la \u00fanica, ni siquiera la mejor, forma de ofrecer im\u00e1genes receptivas. Por un lado, una imagen que funciona a 800 p\u00edxeles de ancho no necesariamente funcionar\u00e1 tan bien en varias fracciones de ese tama\u00f1o.\n<\/p>\n
\n Para lidiar con esto, puede usar una consulta de medios para mostrar diferentes versiones de la imagen dependiendo del tama\u00f1o de la ventana gr\u00e1fica usando una consulta de medios y mostrar: ninguno.\n<\/p>\n
\n CSS:<\/strong>\n<\/p>\n@media (min-width: 601px) {\n#croppedImage\n{\ndisplay:none;\n}\n}\n@media (max-width: 600px) {\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n HTML:<\/strong>\n<\/p>\n<img id=\"largeImage\" width=\"400\" height=\"400\" alt=\"\" src=\"images\/largeImage.webp\" \/>\n<img id=\"croppedImage\" width=\"200\" height=\"200\" alt=\"\" src=\"images\/croppedImage.webp\" \/><\/code><\/pre>\n\n Esto le permite mostrar diferentes versiones de una imagen, en lugar de solo la misma imagen en diferentes tama\u00f1os. Sin embargo, no reduce el n\u00famero de bytes. De hecho, el tama\u00f1o total de la p\u00e1gina ser\u00e1 mayor, ya que se cargar\u00e1n todas las im\u00e1genes, se muestren o no.\n<\/p>\n
\n Una mejor alternativa, si es pr\u00e1ctica, es usar im\u00e1genes de fondo en lugar de <img src=\"https:\/\/inform.click\/wp-content\/uploads\/2024\/11\/inform.click\" \/><\/code>elementos. Esto es preferible porque las im\u00e1genes a las que se hace referencia en CSS se cargan solo si se usan (siempre que no sean URI de datos):\n<\/p>\n@media (min-width: 601px) {\n#largeImage\n{\nwidth:400px;\nheight:400px;\nbackground-image:url(\/images\/largeImage.webp);\n}\n#croppedImage\n{\ndisplay:none;\n}\n}\n \n@media (max-width: 600px) {\n#croppedImage\n{\nwidth:200px;\nheight:200px;\nbackground-image:url(\/images\/croppedImage.webp);\n}\n#largeImage\n{\ndisplay:none;\n}\n}<\/code><\/pre>\n\n Esto funciona bien: los visitantes descargan solo las im\u00e1genes 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\u00e9n podr\u00eda resultar en que los motores de b\u00fasqueda ignoren im\u00e1genes importantes.\n<\/p>\n
\n En su lugar, \u00bfpor qu\u00e9 no usar SVG (gr\u00e1ficos vectoriales escalables): un formato de imagen que escala por su propia naturaleza? Las im\u00e1genes SVG tambi\u00e9n tienen la ventaja de que se pueden dise\u00f1ar f\u00e1cilmente con CSS (consulte este excelente tutorial<\/a> sobre c\u00f3mo hacer que los SVG respondan con CSS). Esto es perfecto para \u00edconos y logotipos, pero desafortunadamente, no podr\u00e1 usar SVG para fotos; para esto, tendr\u00e1 que recurrir a formatos rasterizados, como JPEG.\n<\/p>\n\n Otra opci\u00f3n es usar una de varias soluciones de JavaScript para entregar im\u00e1genes receptivas. Esta es una forma popular de hacerlo, pero agrega otra capa de complejidad. Adem\u00e1s, dado que JavaScript bloquea la construcci\u00f3n de DOM, cualquier soluci\u00f3n 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\u00f3n, hasta cierto punto, se est\u00e1 resignando al menor de los dos males.\n<\/p>\n
\n Hasta hace poco, estas eran las \u00fanicas opciones.\n<\/p>\n
\n Ahora, sin embargo, los elementos y <source \/><\/code>, y los atributos srcset y tama\u00f1os, finalmente est\u00e1n trayendo im\u00e1genes realmente receptivas a la web. La nueva especificaci\u00f3n tambi\u00e9n est\u00e1 comenzando a ganar soporte para navegadores, con soporte completo en Chrome y Opera, y soporte para cambio de resoluci\u00f3n en Safari. Hasta que otros navegadores se pongan al d\u00eda, hay un excelente polyfill<\/a> de JavaScript .\n<\/p>\n\n En este nuevo y valiente mundo, puede usar srcset para establecer una lista de im\u00e1genes candidatas para que el navegador elija. Luego puede usar una consulta de medios en el atributo de tama\u00f1os para dictar el tama\u00f1o en el que se mostrar\u00e1 la imagen. Usando el elemento junto con las consultas de medios dentro de uno o m\u00e1s elementos, puede especificar un rango diferente de im\u00e1genes para diferentes condiciones (por ejemplo, para ventanas gr\u00e1ficas de hasta un cierto ancho, use la imagen a, b o c, y para ventanas gr\u00e1ficas m\u00e1s grandes use la imagen x, y o z). Esto es \u00fatil si necesita entregar una versi\u00f3n recortada de una imagen para usuarios con pantallas peque\u00f1as.\n<\/p>\n