Hola, Choan. Celebro que estemos de acuerdo en mantener las css separadas, al menos en la fase de desarrollo.
Para acortar el tiempo de carga de las css, como ya habéis comentado, se puede adoptar la estrategia de unirlas en una sóla (una única petición al servidor) o usar el método de los alias que plantea Mauricio y cargarlas en paralelo. En principio, el segundo método debería de ser más rápido (lo siento, no es lo que dije en el anterior mensaje). Pero da igual... el tiempo que se gana por cualquiera de los dos métodos no es significativo. Lo que sí puede ser efectivo es aplicar el método de los dominios que cuenta Mauricio pero A TODOS LOS RECURSOS (en especial a las imágenes si hay muchas). En la dirección que te dejé en el mensaje anterior http://www.ajaxperformance.com/2006/12/18/circumventing-browser-connection-limits-for-fun-and-profit/ tienes un ejemplo en donde disminuye el tiempo de carga en un 40% cuando se realizan 6 accesos en paralelo al servidor en lugar de dos. Las temporizaciones las ha tomado la aplicación de rendimiento online que ofrece http://www.gomez.com/ Sin embargo, en las pruebas del equipo de yahoo que explican en http://yuiblog.com/blog/2007/04/11/performance-research-part-4/#what-if llegan a la conclusión de que subir el número de accesos simultáneos por este método puede ser perjudicial, pudiendo ser un número óptimo entre 2 y 4 conexiones en paralelo. Además, la resolución dns que se produce en la primera carga de una página del sitio también puede ser perjudicial, aunque quedarán cacheadas y apenas intervendrán en la temporización para las sucesivas páginas del sitio. Resumiendo: En mi opinión, mejor tener las css separadas. Ganaremos poco uniendo las css a menos que tengamos una cantidad realmente alta. Por otro lado, el método que plantea Mauricio de subdominios a la misma ip podría funcionar si se aplica sobre todo a las imágenes ya que son los recursos más usados. Sería interesante que Mauricio nos dijera el resultado de sus pruebas. Saludos P.D. Choan, no hace falta que vuelvas a repetir lo que has dicho en este hilo, sobre todo para los puntos en los que coincidimos. El 26 de marzo de 2009 18:12, Choan Gálvez <[email protected]>escribió: > Hola. > > On Mar 26, 2009, at 17:39 , Daniel Navarro wrote: > > > Hola, preguntaste: > > > >> Sí, hombre, si ya sabemos que funcionar funciona. Lo que yo me > >> pregunto es si es más eficiente servir N ficheros de X tamaño desde N > >> dominios que servir un fichero de N*X tamaño desde un dominio. Para > >> distintos valores de N y X y eso. > > > > Evidentemente, un sólo fichero con todo aglutinado tardará menos, pero > > ¿concatenarás todos los recursos además de las css?. El límite de 2 > > conexiones se aplica también a las imágenes, por ejemplo. > > > > Cuando se amplía el número de conexiones paralelas, el tiempo de > > carga puede > > ser más que apreciable: > > > http://www.ajaxperformance.com/2006/12/18/circumventing-browser-connection-limits-for-fun-and-profit/ > > > > No creo que merezca la pena unir las css en una sola por varios > > motivos: > > - Apenas se notará la diferencia de tiempo. > > - El navegador cachea las css por lo que las demás llamadas serán > > locales. > > - La separación de css permite gestionarlas de forma más efectiva. > > > > Por lo tanto, es preferible tener los ficheros de hojas de estilo > > separados > > frente a la pequeña ventaja de una inapreciable carga más rápida en la > > primera llamada al sitio. Sin embargo, la opción que plantea > > Mauricio sí que > > puede ser interesante. Particularmente, como en el proceso de diseño > > hay > > tantos parámetros a tener en cuenta (compatibilidad navegadores, > > optimización motores de búsqueda, etc.) prefiero reducirlos al > > mínimo, al > > menos al principio. Eso no quita para que se unan algunos archivos > > css en > > uno solo como, por ejemplo, los de jquery. > > Supongo que cada vez que escriba a la lista tendré que contar mi vida. > > Resumo mis mails anteriores en este mismo tema: > > """ > Si el paquete de ficheros se usa siempre completo, concaténalos y > sírvelos en una sola petición (pero sigue desarrollando por separado, > que ahí sí que vas bien). > > Si no se usa todo el paquete, concatena lo que sea común y añade una > referencia extra cuando corresponda. > """ > > """ > Ahora, cabe tener presente lo que comentaba antes... si tienes un > fichero CSS para pintar un selector de fechas y el selector de fechas > solo aparece en un par de páginas del sitio, es muy posible que no > aporte nada incluirlo en el fichero concatenado. > """ > > """ > Utilizar un dominio distinto del de contenido para los recursos tiene > sus ventajas por aquello de que los navegadores no (suelen) realizar > más de dos peticiones en paralelo a un mismo dominio, pero dudo que > servir cada fichero desde un dominio suponga una mejora (por aquello > de ir resolviendo DNS + hacer la petición + la descarga para unos > cuantos ficheros de tamaño chiquitín). > """ > > """ > Lo que yo me pregunto es si es más eficiente servir N ficheros de X > tamaño desde N dominios que servir un fichero de N*X tamaño desde un > dominio. Para distintos valores de N y X y eso. > """ > > """ > Número de ficheros de desarrollo: tantos como te parezca conveniente. > > Número de ficheros servidos en producción: tan pocos como te parezca > conveniente. > """ > > Y finalmente: > > """ > Tu punto de vista equivale a medir la distancia de Madrid a Barcelona > en palmos. > > ¿Qué dice YSlow/Firebug/cualquier otra herramienta que no mida a palmos? > """ > > Si me podéis responder con datos, genial. Si seguimos con teorías no > avanzamos nada. > > Un saludo. > -- > Choan > <http://choangalvez.nom.es/> > _______________________________________________ > Lista de distribución Ovillo > Para escribir a la lista, envia un correo a [email protected] > Puedes modificar tus datos o desuscribirte en la siguiente dirección: > http://lists.ovillo.org/mailman/listinfo/ovillo > _______________________________________________ Lista de distribución Ovillo Para escribir a la lista, envia un correo a [email protected] Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
