Hola, Mauricio. Gracias por la prueba. Has usado Safari, que usa cuatro conexiones simultáneas. Deduzco que en los navegadores como IE7 que usan sólo dos (lo recomendado por la especificación HTTP1.1), la diferencia de tiempos será mayor. No sé si alguna vez aplicaré esta técnica, pero me parece interesante.
Saludos. El 27 de marzo de 2009 5:44, Mauricio Dulce <[email protected]>escribió: > Hola Daniel y Choan, aca muestro un ejemplo de tiempos de carga en una > aplicación rails > > 1 ejemplo aplicando subdominios a carga de imagenes, hojas de estilos, > javascript, 3 subdominios > http://img49.imageshack.us/img49/5553/imagen3.png > > 2 ejemplo, mismo sitio con configuracion normal > http://img520.imageshack.us/img520/3788/imagen3212931.png > > tanto el cache del browser como el de la aplicación fueron borrados y > el vps reiniciado. > > > El 26/03/2009, a las 21:27, Daniel Navarro escribió: > > > 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 > > Mauricio Dulce > [email protected] > +57 315 4183043 > http://www.3zona.com > > _______________________________________________ > 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
