html - que - sprite redes sociales

¿Por qué usar una hoja de sprites en lugar de imágenes individuales?

Question

Una cosa que he notado en algunos sitios es que usan una imagen BIIIIIIIG que contiene muchas imágenes pequeñas, luego usan background-position CSS para definir las coordenadas de cada imagen, en lugar de usar imágenes individuales.

Aquí es donde estoy:

Contras para usar una gran hoja de sprites

• Necesita cargar una imagen grande para solo mostrar una imagen pequeña
• Necesita escribir (o generar) una hoja de estilo larga con una clase para cada imagen
• El desorden de CSS con muchas definiciones de clases puede afectar el rendimiento
• Si una imagen cambia (o se agrega otra), se pueden encontrar problemas de caché tanto en la imagen como en el CSS asociado a ella
• Requiere un <div> con el estilo adecuado ( display: inline-block; width: 32px; height: 32px; background-image: url(''spritesheet.png''); ) que agrega otra clase más a la mezcla.
• Muchos más que no puedo recordar ahora los estoy escribiendo.

Pros para usar una gran hoja de sprites

• ... Erm ... ninguno todavía.

De hecho, lo único que se acerca a un profesional es que cuando corté la hoja en imágenes individuales, la carpeta resultante tomó 3Mb en el disco (debido a que cada archivo es <100 bytes y mi tamaño de asignación es 4k). Los propios archivos en sí tienen menos de la mitad del tamaño de la hoja y el CSS, por lo que incluso con la sobrecarga de una solicitud HTTP hay un gran ahorro de espacio .

Básicamente, mi pregunta es: ¿Alguien tiene CUALQUIER beneficio para usar una hoja grande sobre imágenes individuales?

Answer 1

Google lo describe aquí . Básicamente, debería reducir el tiempo de carga de la página. Cada nueva inicialización de conexión agrega algo de retraso. En algunos casos, también puede reducir el tamaño de transferencia de datos y, por lo tanto, también reducir el tiempo de carga de la página. Es adecuado para imágenes que cambian rara vez o todas juntas (temas). Entonces el navegador puede usar imágenes almacenadas en caché y necesita verificar solo un archivo para ver los cambios, no todas las imágenes, una por una.

Answer 2

No mucho de lo que dijiste como Cons realmente son contras en absoluto.

Cuando carga una imagen grande, contiene solo uno de los diferentes atributos que necesita una imagen (tabla de colores, tipo de mimo, etc. ex: imagínese si está utilizando un formato jpg progresivo, una hoja de imágenes con imágenes le permitirá escanear la imagen una vez, mientras que muchos disminuirán significativamente el tiempo de carga) en lugar de tener la misma información en 100 archivos diferentes, se reducirá el tamaño del archivo en la imagen completa.

Además, solo habrá UNA solicitud HTTP (o dos, dependiendo de la cantidad de hojas de sprites que tenga), pero si se maneja correctamente, solo una por carga de página.

Si está utilizando imágenes BG en CSS, entonces ya ha creado los selectores CSS para que no haya trabajo adicional, solo copie y pegue la URL.

Nunca he encontrado problemas de caché con spritesheets que no se puedan resolver presionando ctrl + F5.

No requiere un div con el estilo adecuado en cualquier caso. Este no es un método de reemplazo de etiquetas <img> , se usa principalmente para imágenes bg. Me gusta para botones y conjuntos de iconos.

Los profesionales superan con creces los inconvenientes de este método, la prueba es que muchos desarrolladores han comenzado a usarlo. Si fuera un método terrible, nadie lo hubiera recogido y alguien ya hubiera planteado estos problemas cuando se usó por primera vez.

Si alguien tiene más que agregar, no seas tímido :)

Answer 3

Sí, cantidad de solicitudes.

La mayoría de los navegadores solo descargarán alrededor de 2 recursos por dominio en paralelo, de modo que si se sirven muchas imágenes pequeñas, el usuario tiene que esperar alrededor de la mitad de los ciclos de solicitud-respuesta HTTP. Si usas un sprite, esa es solo una solicitud y una respuesta (aunque una respuesta más grande).

Answer 4

Si tiene muchas imágenes, el navegador deberá descargar todas y cada una de ellas. Como el navegador solo puede descargar una cantidad limitada de archivos simultáneamente, llevará tiempo. Una sola imagen solo vinculará una ranura de descarga permitiendo que la página rinda más rápido.

Además, si se usa en muchas otras páginas, la hoja de sprite grande ya estará en caché.

Answer 5

esto es especialmente bueno para muchas imágenes pequeñas, porque el navegador solo tiene que hacer una solicitud http para todas las imágenes, y no cientos de ellas. Así que cargas web mucho más rápido en el navegador del cliente.

la cosa es la velocidad de carga. Solo una solicitud HTTP es bastante más rápida que docenas de ellos.

Answer 6

Además, ayuda a mantener su CSS más limpio. Por ejemplo, uso sprites para botones (lo que también significa que no hay demora adicional para cargar el img de estado de desplazamiento)

<button type="submit" class="vorige"><span>Vorige</span></button>
button {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover {background-position: 0 94px; cursor: pointer;}
button:active {background-position: 0 47px;}
button span {display: none}
.vorige {background-image: url(../img/button/btn_vorige.png);}
.volgende {background-image: url(../img/button/btn_volgende.png);}
.verstuur {background-image: url(../img/button/btn_verstuur.png);}

debido al sprite puedo omitir el código para una imagen separada de vuelo estacionario:

.vorige:hover {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}

Answer 7

Las hojas de Sprite son un desastre. Período. No es necesario azucararlo. Presentan un enorme retroceso en la tecnología de diseño, lo que probablemente explica por qué las únicas personas que les gusta usar hojas de sprites son desarrolladores de juegos de la vieja escuela. Las hojas de Sprite solo tienen una calidad de redención, son un poco más rápidas de cargar. Aparte de eso, son basura. Sin mencionar una pesadilla para establecer.

¿En qué mundo es "aceptable" tener que incluir 500 líneas de código solo para ejecutar un ciclo de caminata simple? Afortunadamente, algunos tipos inteligentes encontrarán una solución tan simple como arrastrar un formato de video compatible con alfa, como flv, pero que también se ejecutará en tabletas ...

Si te apetece escribir una lista masiva de lo grandiosos que son los sprites, solo me pregunto qué tan aburrido debe ser tu trabajo de diseño. La conclusión es que si una "herramienta" hace que sea más difícil para usted hacer cosas que deberían ser fáciles, entonces no es una buena herramienta. Tirar a la basura.

Answer 8

El objetivo es reducir las solicitudes HTTP. Además, a veces el sprite comprimido pesará menos que las imágenes originales.

Recientemente tuve un sitio web con muchos degradados transparentes (blanco a trans, gris a trans) y algunos en blanco y negro en imágenes transparentes. Poniéndolos a todos en un sprite y reduciendo los colores en el png a 8 pude hacer que el sprite sea más pequeño en tamaño de archivo que las imágenes originales (solo ... fue aproximadamente un ahorro del 0.5%). Al reducir el número de solicitudes HTTP de 10 a 1, el sitio se cargó más rápido (si se midió el tiempo desde la primera conexión hasta todos los datos transferidos).

En ese caso, se encontró un aumento mensurable.

Aunque estoy de acuerdo en que es posible complicar las cosas y terminar con un sprite más grande de lo necesario, especialmente si no estás usando compresión PNG.

Tenga en cuenta dos años después de publicar esto: si está utilizando SSL, debe buscar en SPDY (mi nota en dos años más mencionará HTTP 2.0 en lugar de SPDY). SPDY niega los beneficios de spriting.