Vigencia de Google Page Speed y Yahoo! YSlow

Estos días se están haciendo revisiones en algunos sitios de la validez que tienen los puntos que definió Steve Souders hace ya algunos años (entre dos y tres) para saber si siguen vigentes, teniendo en cuenta que los navegadores han evolucionado exponencialmente estos últimos años. Hay que tener en cuenta que las herramientas de Google Page Speed y de Yahoo! YSlow se basan en estos datos pero… ¿siguen siendo vigentes los resultados de estas herramientas? Creo que la respuesta es que en algunos casos no.

Comencemos repasando los de Yahoo! (que al final es la plantilla en la que se basan ambos), que fueron los primeros en aparecer y los que creo que no han evolucionado ni actualizado.

  • Minimize HTTP Requests: Creo que no cabe duda de que esto siempre será válido… cuantas menos peticiones, menos tiempo se pierde.
  • Use a Content Delivery Network: Esto ya no es tan importante, aunque hay que hacer muchos matices. Deja de ser importante generalizarlo a menos que tengas mucho tráfico internacional muy distribuido; si tu tráfico es de un mismo país mayoritariamente, tener un CDN no aporta nada. Tener tráfico internacional en un CDN es interesante siempre que las URL sean las mismas independientemente de la localización.
  • Add an Expires or a Cache-Control Header: Esto también es siempre algo a realizar, incluso si se trata de contenidos dinámicos ya que habría que indicar un tiempo “cero”.
  • Gzip Components: Más que obligar a usar gzip, diría que hay que gestionar bien las cabeceras. Por ejemplo, las imágenes en JPEG no tiene sentido volver a comprimirlas con gzip ya que ya van comprimidas por norma general, por lo que los beneficios son mínimos. Para la parte de contenidos “textuales” (HTML, JavaScript, CSS…) sí que es algo más que recomendable aplicar siempre.
  • Put Stylesheets at the Top: Esto también sigue siendo vigente ya que el navegador es importante que sepa cuanto antes lo que ha de maquetar. Incluiría que es recomendable no usar CSS inline.
  • Put Scripts at the Bottom: No lo tendría tan presente ya que hay que analizar cada caso en cada JavaScript. Hay que tener en cuenta que existen dos tipos y formas de cargar los scripts, ya sean bloqueantes o no, por lo que los “no bloqueantes” hay que colocarlos en la cabecera, junto a los asíncronos, y los “sí bloqueantes” incluirlos al final de la página.
  • Avoid CSS Expressions: Obvio. Además, tengo entendido que Internet Explorer 10 ya no acepta este tipo de códigos, así que un problema menos.
  • Make JavaScript and CSS External: Y, además, como decía antes, evitar los CSS o JavaScript “inline”.
  • Reduce DNS Lookups: En general se le da muy poca importancia a las DNS. A parte de decir que se hagan la menor cantidad de peticiones posibles a las DNS, intentar no usar CNAME y demás, habría que analizar bien qué sistema de DNS utilizar y cómo distribuirlo.
  • Minify JavaScript and CSS: Y además de los CSS y JS, ampliaría la cuestión a intentar minimizar el tamaño de los HTML e incluso de los XML (y de cualquier cosa que tenga “tags”.
  • Avoid Redirects: Esto también tiene sus cosas… Si bien es cierto que hay que evitar al máximo las redirecciones, creo que es “obligatorio” evitarlas en las páginas de destino principales (como puede ser el dominio principal, que al entrar redirija) pero focalizarlo todavía más en algunas situaciones que pueden generar problemas, como tener URL de imágenes que siempre hacen redirecciones, o CSS o JavaScript que se cargan en cada página. Yo excluiría la “navegación” de este punto.
  • Remove Duplicate Scripts: Esto creo que es obvio.
  • Configure ETags: Sí y no. Está bien tener activados los ETags, ya que es el mejor sistema para no tener que re-cachear nada ya que son peticiones mucho más sencillas pero sólo en aquellos elementos que en principio tienden a ser estáticos, como imágenes, scripts y similares. Hacer esto en contenidos como HTML (a menos que sean ficheros HTML físicos) no tiene mucho sentido.
  • Make Ajax Cacheable: Una vez más, depende… en general el AJAX se utiliza para elementos que son muy dinámicos, por lo que cachear no suele tener mucho sentido en estos casos. Lo que sí que hay que plantearse es que el AJAX sea llamado por peticiones GET (y no POST) y que el formato sea JSON (mejor que XML).
  • Flush the Buffer Early: Si bien es cierto que hay un momento clave (que es el de cambiar del head al body, hay que analizar muy claramente los momentos en los que hacer un flush ya que por lo general pierde sentido si no es en ese momento (otro momento sería el de antes de los scripts del final de la página).
  • Use GET for AJAX Requests: Como ya comentaba antes.
  • Post-load Components: Suele tener sentido con las imágenes, aunque de forma limitada solo a aquelas grandes (no se puede aplicar a iconos y similares). Es el llamado “lazy load” y básicamente plantea que, en el momento en el que el usuario tenga la necesidad de ese contenido, se haga la llamada; como ejemplo sería que, en el momento en el que el usuario llegue a la parte de la pantalla (si es larga, pues cuando baja) se cargue la imagen para verla, pero no antes.
  • Preload Components: Este método no es necesario en la mayor parte de los sitios web, ya que son de contenidos y no se puede predecir el comportamiento del usuario. De todas formas sí que se puede plantear hacer una carga de un JS o CSS pequeño para que el usuario comience a ver y trabajar con la página y después cargar un CSS y JS mayor que sirva para todo el resto del sitio. Aplicarlo suele ser bastante complejo y los beneficios son discutibles.
  • Reduce the Number of DOM Elements: En general los sitios no tienen un exceso de elementos DOM. Además, el HTML 5 ya suele implicar una reducción debido a que el webmaster no ha de poner “identificadores” a las etiquetas. En general es algo difícil de controlar.
  • Split Components Across Domains: Está bien plantear el Domain Sharding, pero teniendo en cuenta que los navegadores actuales han pasado de una media de 2-3 peticiones/hostname a una media de 6 peticiones/hostname esta situación queda bastante diluida.
  • Minimize the Number of iframes: Yo diría algo así como: ¡muerte al iframe!
  • No 404s: Creo que esto se ha tomado mal por muchos. La sensación que tengo (al menos esto sí es útil) es que desde el HTML no se hagan llamadas a elementos que devuelven un código 404. Por ejemplo, una llamada a una imagen que no existe, ya que esto genera un bloqueo por parte del navegador. No habría que confundirlo con tener enlaces en tu web a páginas que no existen y devuelven un 404 (que claro está, es mejor no hacerlo, pero no es un problema de rendimiento propiamente dicho).
  • Reduce Cookie Size: Obvio.
  • Use Cookie-free Domains for Components: Básico.
  • Minimize DOM Access: Cuanto más 1.0 sea la página mejor… ya que la página se muestra y así se queda. En cambio, todo lo dinámico implica un sobre esfuerzo por parte del navegador que si no está bien optimizado puede hacer que los scripts bloqueen el programa.
  • Develop Smart Event Handlers: Esto va relacionado con lo anterior. Si te pones y lo haces, hazlo bien. Obvio.
  • Choose over @import: El problema de esto era en los navegadores de finales de los 90. Ahora tampoco tiene mucho sentido, aunque es lógico que vaya más lento ya que implica otra llamada HTTP, con lo que ello supone.
  • Avoid Filters: Como decía antes, Internet Explorer 10 ya se ha cargado esto, así que otro tema menos.
  • Optimize Images: Básico.
  • Optimize CSS Sprites: Lo incluyo en lo de las imágenes… es básico que un Scrite esté bien hecho, sin espacios entre iconos y poniendo las imágenes de forma que el tamaño de la imagen sea el mínimo.
  • Don’t Scale Images in HTML: Básico… hoy en día con la tecnología que tenemos se pueden hacer varias versiones (de tamaño) de una imagen de forma automática o al vuelo y dejarla cacheada.
  • Make favicon.ico Small and Cacheable: Y comenzaría diciendo que simplemente haya un favicon.ico en la carpeta raíz, aunque ocupe “0 bytes”, para que no genere errores 404.
  • Keep Components under 25K: Hoy en día los móviles han evolucionado mucho y las cachés pueden ser tranquilamente de 1 MB, por lo que esto ha quedado completamente desfasado.
  • Pack Components into a Multipart Document: Inútil en general.
  • Avoid Empty Image src: De sentido común.

Si revisamos las de Google Page Speed nos damos cuenta de que esta información sí que ha sido evolucionada y en general va adaptándose a lo actual. En general creo que lo de Yahoo! es básico, y lo que expone Google es más técnico en algunos detalles:

  • Leverage browser caching: En este tema tengo ciertas dudas… lo que indica tiene lógica pero en determinados tipos de fichero puede convertirse en un problema. De todas formas he de acabar de hacer pruebas (en principio estas próximas semanas) así que ya veré.
  • Leverage proxy caching: Sentido Común, nuevamente. Hay que tener presente cómo funcionan los proxies
  • Optimize the order of styles and scripts: Importantísimo. Los scripts bloquean, por lo que si podemos hacer hasta 6 llamadas simultáneas hay que ordenar los elementos de forma que no se bloqueen entre ellos. De esta forma estaría bien plantearse si cruzando CSS y JS podemos conseguir esto.
  • Avoid document.write: Este sistema bloquea muchísimo la carga de las página, ya que hasta que nos e finaliza la misma no se ejecuta, por lo que puede rehacer todo el diseño. Si se usa, que sea en funciones, pero no en el código fuente.
  • Prefer asynchronous resources: Obvio. Ya lo he comentado en varias ocasiones.
  • Remove unused CSS: Obvio, pero. En ocasiones da la sensación de que te estén diciendo que hay que usar un fichero JS y CSS por página, lo que implicaría un aumento de peticiones a corto plazo… Siguiendo con la filosofía de reaprovechar código, en este caso sí que eliminar código que no se use, pero que no se use en ninguna parte de todo el sitio, no de esa página en concreto.
  • Minify HTML: Antes lo dije, pero en lo de Yahoo! no lo comentan.
  • Use efficient CSS selectors: Difícil pero no imposible. Los selectores pueden complicarse, pero con un poco de trabajo se puede conseguir un uso eficiente de ellos. Hay que intentar evitar selectores universales, e intentar ir siempre a lo más específico. Muy recomendable un documento de Mozilla sobre la eficiencia para CSS.
  • Specify image dimensions: Por si no queda claro, ya sea con los parámetros del HTML o a través de CSS.
  • Specify a character set: Básico. Aunque los servidores ya devuelven el contenido en una codificación por defecto, es mejor indicar la meta-etiqueta que informa del ISO o UTF que se está usando.
  • Make landing page redirects cacheable: Error. Las URL han de ser las mismas ya que no hay que diferenciar URL entre escritorio o móvil. Mediante sistemas de web-proxy es fácil conseguirlo.

NOTA: en la parte de Google, los elementos que son igual que en Yahoo! ni los comento.

Entre los análisis de Google Page Speed y de Yahoo! YSlow, ahora mismo el que da información más apurada de lo que es la realidad vendría a ser el de Google Page Speed, pero, hay que recordar que esto son simples directrices, y que aunque estas herramientas se “quejen” no significa que lo que hay está mal, ya que todo tiene una razón de ser. Está bien analizar los mensajes que se dan, pero no siempre hay que corregirlos y obtener un 100/100 de puntuación.

Categorías Javier, WPO

3 comentarios en “Vigencia de Google Page Speed y Yahoo! YSlow”

  1. Muy currado. Yo estoy dándole vueltas a lo de cargar javascript asíncronamente. Según Google lo recomendable es:
    Use a script DOM element

    Using a script DOM element maximizes asynchronous loading across current browsers:

    var node = document.createElement(‘script’);
    node.type = ‘text/javascript’;
    node.async = true;
    node.src = ‘example.js’;
    // Now insert the node into the DOM, perhaps using insertBefore()

    Using a script DOM element with an async attribute allows for asynchronous loading in Internet Explorer, Firefox, Chrome, and Safari. By contrast, at the time of this writing, an HTML tag with an async attribute will only load asynchronously in Firefox 3.6 and Chrome 8, as other browsers do not yet support this mechanism for asynchronous loading.

    Pero lo de insertar el node en el DOM desconozco como hacerlo… ¿Es complicado hacerlo?

  2. Algunos matices, lo del flush no aplicaría si usamos gzip que es la situación ideal.
    Con respecto al e-tag, personalmente creo que es mejor quitarlo y optar pr el par max-age / last-modified ya que el eTag puede variar si usamos varios frontales.

    Por lo demás hay que decir qu podemos hacer wpo en dos niveles, sitios que reciben millones de visitas (portada de elmundo.es por ejmplo) y mi sitio. No hay que ser tan talibanes hasta el extremo.

    También es importante considerar en mejorar la carga, bloques que se pueden cargar en asíncrono, bloques que se posicionan por css y javascript desde la parte inferior…

    Por último, es muy importante mejorar la carga de todos estos externos, ga.js, facebook, g+, tweet this….

    bueno post

Deja un comentario