El archivo Css para impresión y la demora en la carga y dibujado de la web 28.10.14
Efectos del archivo de impresión en la carga y dibujado de las páginas web y alternativas a su inclusión para evitar las demoras.
El archivo Css para impresión y la demora en la carga y dibujado de la web
Varios artículos me han llamado la atención estos días. Todos, con siete años entre la publicación del primero y el último, tratan sobre el mismo tema: el efecto que tiene el archivo Css para impresión <link rel="stylesheet" href="print.css" media="print"> en la carga de la página.
Y pese al tiempo transcurrido entre el primero y el último, nada menos que siete años, y las mejoras introducidas por los navegadores en este tiempo, el efecto de retardo en la carga de la página se mantiene. Y por los datos que ofrecen, no es cuestión valadí.
Los artículos, de los que que este post es un resumen, son:
Delay loading your print CSS
. Junio de 2007 en phpied.com.5 years later: print CSS still sucks
publicado en Abril de 2012 por @stoyanstefanov.Does a print CSS file slow your site down?
aparecido el 17 de Octubre de este año por Alex Painter.
Mi recomendación: Que este post es un mero eco de los artículos anteriores, y por lo tanto lo mejor es que visites los originales [ing]. Pero no antes de terminar con éste ;-) y dejarnos tu opinión o experiencias al respecto en un comentario.
media='print' y su incidencia en la carga de la página
Tengamos la típica llamada a los archivos Css: el genérico o para pantallas y el destinado a controlar la impresión de la web en medios paginados:
<link rel="stylesheet" href="screen.css" media="screen">
<link rel="stylesheet" href="print.css" media="print">
Escenario 1
Ambos autores tras diversas pruebas certifican el retraso en la carga de la página. La imagen de abajo, resume las llevadas a cabo por Alex Painter.
Caso 1 Un archivo CSS impresión fue colocado como segundo objeto en el head vía <link..., después de un archivo CSS (de terceros), pero antes de cualquier otro contenido, incluyendo los principales ficheros (screen) CSS, imágenes y JavaScript.
Más que ilustrativa la imagen: Los IE´s (8, 10 y 11) y Firefox tardan más de 15s en comenzar a dibujar la página. El bloqueo en su composición por parte del archivo de impresión es patente.
Escenario 2
La siguiente prueba se realiza desplazando la llamada al archivo de impresión para que sea el último en aparecer en el documento. Justo antes de cierre del html </html>. Ya advierten los dos autores que ésto, en caso de validar tu documento, hará saltar un bonito error: documento no válido
.
La diferencia respecto a la imagen y escenario anterior queda más que patente en los tiempos mostrados: se pasa de más de 15s en todos los navegadores (menos IE8) a poco más de 1s.
Para las explicaciones sobre los detalles y particularidades en cada navegador en cada una de las pruebas (como por ejemplo el porqué del retraso en la carga de imágenes afectadas por jQuery) visita el artículo original de nccgroup.com.
Acciones posibles y recomendaciones
En el caso de que tu página se esté viendo afectada en su carga y dibujado por algún archivo Css de impresión, tres son las soluciones posibles.
Incluye la reglas de impresión en el Css general
La primera sugerida por ambos autores es incluir todas las reglas destinadas a controlar la impresión de la web en el archivo Css general mediante la regla @media print { } al final del documento:
/* reglas generales del Css */
@media print {
/* reglas particulares para impresión */
}
Desplaza la llamada <link media='print'>
La ya mencionada y usada en las pruebas: colocar la llamada al archivo de impresión justo antes del cierre del html. Con la advertencia de que un elemento <link ...> sólo puede estar incluido en el <head> y que al colocarlo fuera de él es marcado como erróneo (aunque funcione).
Demorar la creación del <link media='print'>
Otra posible solución es crear el enlace al archivo Css destinado a la impresión una vez creado el DOM y cargada la página. Bien mediante javascript, jQuery o cualquier otro lenguaje de programación que lo permita y uses.
Kseso
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
Desde mi punto de vista (ya me corregirá Kseso si estoy equivocado, cosa que además agradezco) tener el CSS repartido en 2 o más archivos no es lo más correcto dado que al incrementar las peticiones incrementamos el tiempo de carga (aunque solo sean milisegundos o segundos como en este caso extremo). Entonces yo me quedaría con la solución de incluirlo en el CSS principal mediante [code]@media print { }[/code] que además es de lo más elegante.
ResponderEliminarHola Jaime
EliminarNi me gusta ni es mi intención corregir a nadie. Sí me gusta exponer y confrontar mis ideas / opiniones con las vuestras y con algo de suerte sacar todos algún beneficio.
Respecto al tema del artículo:
Me he limitado a traer aquí un resumen de los post que enlazo al inicio. No hice ninguna prueba, así que lo siguiente son suposiciones:
.- Supongo que el retraso tan significativo será tanto más notable cuanto mayor sean las hojas de estilo.
.- En caso de topar con este problema seguramente lo mejor fuese crear el <link media="print"...> una vez terminada la carga de toda la página.
Estamos hablando de un archivo Css que será necesario de cuando en vez y sólo tras algunas acciones del usuario.
Así que tampoco pasa nada por demorar su "disponibilidad".
Porque si es lo suficientemente extenso el Css general, imagina qué puede ocurrir si lo aumentas con el @media print { }
Un saludo y gracias por tu opinión.
Si los navegadores tienen tanto problema para incorporar los estilos de impresión, también me parece que las mejores opciones son las de agregarlos de manera dinámica, o antes del fin de la página.
ResponderEliminarEl primer caso es bastante sucio, habrá que tenerlo en cuenta sólo porque existen "fallas" que hay que salvar de cualquier manera.
El segundo me parece mejor, porque nunca me importó mucho la validación de un documento que funciona. Sin embargo, debe haber una manera de hacerlo válido ¿Se podrá inventar algo con el atributo 'scope'?. No es muy compatible, pero al menos es válido para HTML5.
scope tiene varias limitaciones, Furoya para el caso del artículo:
Eliminar1ª: después de que Chrome (blink) le retirase su soporte sólo queda funcional en Firefox
2ª: El atributo scoped lo único que hace es limitar el alcance de las declaraciones contenidas en él al elemento que contiene al elemento <style... y a sus hijo. Evita su propagación (por herencia o cascada) fuera de su contenedor padre.
3ª: Su descarga se inicia en el momento de encontráselo el navegador según lee el documento.
Así que sin pensar demasiado en ello, creo que lo mejor (de presentarse el problema) sería construir el enlace una vez cargado el documento, como le decía a Jaime