Te invito a una comida si haces la misma prueba con el Menéame, me interesaría ver cómo se comparan los números (fuimos muy cuidadosos en eso, además de los estándares, aunque no nos atrevemos a unificar imágenes, mucho curro para poca ganancia relativa )

Tienes razón con la frase: “te damos de todo para que estés contento” Nunca me expliqué porqué esa manía de recargar tanto que luego lo único que genera es una sensación de “me pierdo algo” cuando cambias de página. Debe ser que siguen pensando en papel y que como la tinta cuesta poco –menos que el papel– menjor llenar cada página.

PS: me parece que los sripts/imágenes de estadísticas externas son los que más tardan

Yo también me apunto a que hagas el test en spaniards.es, a ver que tal sale la web parada.

Yo creo que hoy día los periódicos se encuentran en la encrucijada de ofrecer la máxima información posible sin desbordar al lector. Está claro que en los buscadores pueden coexisitir ambas alternativas: portal cargado, como Yahoo, o simple, como Google. Pero un periódico con una página principal como la de Google no tedría mucho futuro (¿o quizá sí?)

Leer el periodico desde el movil es desesperante y eso sin hablar de los interstitial

Ya que estamos puntualizando entonces hay que aclarar que UNA pagina no es, en conjunto, mas pequeña si se siguen los estándares. De hecho todo lo que forma UNA página es más grande si se siguen estándares que si no (ya solo el que se requieran más atributos, las etiquetas suelan ser mas grandes, etc. ya suma). El usar estándares hace que EL CONJUNTO de páginas de un sitio sea mucho menor.

Utilizar estándares facilita la carga (menos quirks, menos esfuerzo del navegador) y aprovecha a enviar parte de la carga adonde puede ser cacheada (javascript, css, etc.). Dependiendo del sitio web a partir de la segunda o tercera página el peso total va a ir disminuyendo comparado con el sitio antes de estandarizar.

Esto es lo que es y no es discutible, son matemáticas puras. “span class=emphasis” es mas largo que “i” y “strong” es mas largo que “b”. Es así por diseño. Se sacrifica tamaño a cambio de unificación y separación de esfuerzos.

Sobre lo que dice Ricardo si, los scripts de estadísticas externos son siempre los que más se pasan. Google Analytics, Mybloglog, Hittail, etc. Esto es porque estos hacen mucho malabarismo para sacar toda la información que recolectan y porque el navegador requiere un cambio de contexto al ir y buscar y ejecutar y responder a un script en otro dominio. En wordpress llevo un tiempo mirando el plugin cystats que a mis ojos guarda tanto o más información que, por ejemplo, google y no me parece una mala alternativa funcional en casi todos los escenarios que requieren estas estadísticas.

totalmente de acuerdo, y con respecto a eso que dices:
“…ahora ha cambiado mi forma de ver y emprender el desarrollo de cada proyecto”
Ha mi también me paso cuando leí un articulo que hablaba sobre como influenciaba cada petición http en la carga de la página.
Pero claro, despues de tener que explicar a mi “jefe” porque juntaba las imagens de fondo y decir que los diseños(de una página que ahora es bastante lenta) no estaban pensados en la magnitud de acceso que tendría esa web, y decirme: “3 megas no es mucho”; ya no he vuelto a hacerles el test con el firebug
gran articulo

Gracias Diego. Se nota la diferencia cuando te preocupas mínimamente en hacer eficiente las descargas (y yo tampoco soy un experto en eso).

Gracias Diego! Nos gusta comentar ese tema, porque le dimos mucha importancia. Es mejor para los visitantes y para nosotros visto el éxito del lugar. Menos ancho de banda, menos carga del servidor permite ahorrar mucho en hosting. Algunos lugares con menos visitas tienen incluso el cuadruple de servidores que nosotros.

La extensión Lori del Firefox dice que 62.43 KB, ahora mismo, para 38 peticiones. Posiblemente Lori cuenta los bits que llegan y no los que pinta el navegador; en menéame comprimimos.

No puedo mirar el tiempo de respuesta en este momento, estoy subiendo un par de videos a Google Video y prefiero no pararlo –Google Video falla más todavía cuando paras la subida

Estaría bien ver las estadísticas de los grandes foros españoles:

http://www.media-vida.net, http://www.putalocura.com, http://www.elotrolado.net, http://www.forocoches.com

Tanto en portada como en el foro, claro

Me da a mí que más de uno se va a llevar una sorpresa…

mini-d, para firebug hay una extensión creado por Yahoo: YSlow que te checkea la velocidad, te la puntua, y te dice que puntos flojean y hay que mejorar.
Te pongo un link que puede ser interesante para la optimización de un sitio: http://www.ipsojobs.com/blog/2007/10/15/cache-and-gzip-your-javascripts-and-csss-files-to-speed-up-your-site/

Justo ayer dejé un comentario en 20minutos diciéndoles que me gustaba el nuevo servidor a pedales que habían instalado. (JUASJUAS)

@eduo, tu “span class=’emphasis’” podría reducirse a un em, y aunque strong sea más largo que b, todo el churro que le meterías a un paragraph, o una etiqueta horrorosa font, hace que de por si una página xhtml+css sea mucho más pequeña en tamaño. Básicamente porque, aunque pongas class=”tal” en cada etiqueta, te ahorras todo el código que hubieras puesto duplicado si el código de formato, colores, etc estuviera en-linea.

El análisis que ha hecho Diego está bastante interesante. No ya por el dato de los tiempos de carga, ya que puede depender de mil factores como conexión, saturación del upstream, bla bla, sino por el hecho que señala de que la gente se va colgando medallas por usar estándares, cuando luego no lo hace necesariamente como debiera. El desarrollo de páginas web es algo que se debe planificar tanto como cualquier otra “aplicación”… debería diseñarse teniendo en cuenta estos factores importantísimos. Quizás con más artículos como este se empiece a valorar el trabajo de los profesionales frente al de los “profesionales”.

Y bueno Diego, no he utilizado el Webkit (no uso Safari, aunque por curiosidad, ¿también lo trae la versión Windows?), pero el Firebug de pocos datos nada, échale un vistazo últimamente. Quizás no te ordena los contenidos comprimidos de los no-comprimidos, pero sí te dice si lo está o no. En la pestaña de Net, cada elemento desplegable con sus headers y response, no sé, a mi me parece bastante info. Ten en cuenta que no he visto Webkit, así que puede que por eso me parezca tan bueno firebug ^^.

Hola, me gustaría saber como poder mirar el tiempo de carga de mi web y dónde se encuentran la mayor parte de los megas de carga.
Considero que tengo una web poco cargada, pero los tiempos de espera me resultan algo largos con respecto a lo que yo creo que debería.

Las web es http://www.herzeleyd.com

Un saludo

Este es un punto que siempre me ha parecido muy importante, porque por más banda ancha que uno tenga, cada archivo que signifique otro “viaje” al servidor incide directamente en el performance y velocidad de carga. Desgraciadamente el concepto de manejar gráficos por medio de una grilla y CSS es un concepto aún alienígeno para la inmensa mayoría de diseñadores del medio. Pero mientras la mentalidad de que todo mundo hoy día tira de banda ancha (falso) y por tanto estas cosas “ya no importan”, no creo que la situación vaya a cambiar mucho. Qué diferente la mentalidad de aquellos tiempos de los módems a 56k en donde cada KB de menos o de más hacía toda una diferencia. El que una página valide con la W3C no significa per se un soporte implícito y total de los estándares web.

ALT1040 es una verguenza, ¡¿como puedes tener una portada de 2MB y no darte cuenta?!

Interesante, lo voy a tener en cuenta.