El 26 de marzo de 2009 21:44, Mauricio Dulce <mauricio.du...@gmail.com>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 > > <choan.gal...@gmail.com>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 Ovillo@lists.ovillo.org > >> 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 Ovillo@lists.ovillo.org > > Puedes modificar tus datos o desuscribirte en la siguiente > > dirección: http://lists.ovillo.org/mailman/listinfo/ovillo > > Mauricio Dulce > mauricio.du...@gmail.com > +57 315 4183043 > http://www.3zona.com > > _______________________________________________ > Lista de distribución Ovillo > Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org > Puedes modificar tus datos o desuscribirte en la siguiente dirección: > http://lists.ovillo.org/mailman/listinfo/ovillo > Realizaste la prueba 1 vez o es una promedio de varias? -- ________________________________________ Lo bueno de vivir un dia mas es saber que nos queda un dia menos de vida _______________________________________________ Lista de distribución Ovillo Para escribir a la lista, envia un correo a Ovillo@lists.ovillo.org Puedes modificar tus datos o desuscribirte en la siguiente dirección: http://lists.ovillo.org/mailman/listinfo/ovillo
