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
