Aprende cómo resolver los problemas detectados por PageSpeed Insights

Cuando ejecutamos la herramienta de diagnóstico PageSpeed Insights de Google, obtenemos una valoración del rendimiento del sitio web y un informe de los problemas detectados y recomendaciones para resolverlos. Sin embargo, éstas no ayudan a resolver todos los problemas y podemos llegar a un callejón sin salida. Veamos cómo reducir (en muchos casos, incluso eliminar) todos los problemas de este informe.

Tiempo medio de lectura: 15 min (4.700 palabras).
Si no tienes tiempo ahora, puedes saltar directamente a las conclusiones del artículo.

Tabla de contenidos


Guía de hosting WordPress y mejores optimizaciones

El Posicionamiento Orgánico sólo tiene ojos para el PageSpeed Insights

El Posicionamiento Orgánico en Google toma referencias de PageSpeed Insights
Ten los ojos bien abiertos para mejorar tu SEO

Una de las áreas más frustrantes del SEO técnico la padecemos con los informes de Google PageSpeed Insights. Por dos razones: (1) por un lado, solo nos identifica los problemas que ha encontrado, pero muchas veces sin una solución, recomendación o pauta claras sobre cómo localizarlo y resolverlo; y (2) porque tiene un efecto crucial sobre el posicionamiento orgánico de cada página web en particular y del sitio web en general.

PageSpeed Insights no es única. Disponemos de muchas otras herramientas de diagnóstico (como pingdom, GTmetrix o WebPageTest) que incluso ofrecen mejores y más completas métricas para evaluar el rendimiento de nuestras páginas web. Sin embargo, sus puntuaciones no son tan relevantes: a la hora de la verdad, nuestro sitio web puede tener una puntuación perfecta en todas esas herramientas pero Google sólo prestará atención al análisis de su herramienta.

Por tanto, debemos centrar nuestros esfuerzos en resolver los problemas que destaca en sus informes. Aún así, no deberíamos descartar las otras herramientas, puesto que en algunos casos nos podrán ayudar a identificar la causa de algunos de dichos problemas, sobre todo para sitios webs grandes y complejos, en los que resolver un problema puede tener más de una causa.

Además, comparado con los informes de estas otras herramientas, el informe de PageSpeed Insights no utiliza demasiada “jerga” técnica y no requiere tener una alta cualificación técnica para comprenderlos y, en muchos casos, resolverlos. Por dicho motivo, es la herramienta ideal para cualquier propietario de un blog o sitio web de tamaño medio, sin un número demasiado elevado de visitas, que sólo tiene que ser experto en su especialidad y no puede disponer de un equipo técnico.

Eso sí, a medida que el sitio web o las visitas aumentan, la valoración de PageSpeed Insights se resentirá aunque sigamos las recomendaciones incluidas en este artículo, debido a que intervienen otros factores mucho más sutiles que los que identifica PageSpeed. En este caso, no queda más remedio que utilizar las herramientas más especializadas y uno o más técnicos cualificados para identificarlos y resolverlos, puesto que puede afectar a áreas de desarrollo, diseño web, gestión de base de datos o gestión de servidores, entre otros.

 

¿Cómo funciona el análisis de rendimiento de PageSpeed Insights?

Cómo interpretar el informe de rendmiento de PageSpeed Insights
La maquinaria de PageSpeed Insights en plena marcha

En este artículo nos vamos a centrar en el análisis que PageSpeed Insights realiza para medir el rendimiento de un sitio web, común para entornos móviles y ordenadores de escritorio.

La herramienta también realiza, para entornos móviles, un análisis de la experiencia de usuario, enfocado a la visualización gráfica del sitio web en las pequeñas pantallas de los dispositivos móviles, pero no vamos a abordarlo aquí. Si estás interesado en saber más sobre experiencia de usuario en móviles, puedes consultar este artículo.

El análisis de PageSpeed Insights se basa en la verificación y cumplimiento de un total de diez reglas. Para medir el grado de satisfacción de estas reglas, el informe de PageSpeed utiliza un código de colores similar a los semáforos:

  • Color verde, para indicar que la regla se satisface totalmente.
  • Color naranja, cuando la regla no se satisface totalmente pero no tiene un gran impacto en la valoración final.
  • Color rojo, para aquellas reglas que, al no satisfacerse, tiene un alto impacto en la valoración final.

Por tanto, nuestra prioridad siempre será resolver cuanto antes las reglas evaluadas en color rojo, aunque sea para convertirlas en color naranja, con lo que ya obtendremos una sustancial mejora de la valoración final. Solo entonces deberíamos prestar atención a las notificaciones de color naranja, pero sabiendo que no son tan críticas.

Por último, señalar un aspecto importante al evaluar el rendimiento de nuestro sitio web: distintas ejecuciones de la herramienta de análisis puede (de hecho, suele) dar puntuaciones distintas, dentro de un rango de hasta 6-8 puntos.

Esto es completamente normal, puesto que hay multitud de factores que pueden intervenir durante el análisis de rendimiento y completamente ajenos al propio sitio web, como el volumen del tráfico web en ese preciso instante, el estado y capacidad disponible de las líneas de conexión utilizadas, la carga del servidor de alojamiento (sobre todo si es compartido), etc.

 

Las 10 Reglas del Análisis de Rendimiento de un vistazo

La imagen que siempre quisiéramos obtener con PageSpeed Insights sería la siguiente:

Informe completo 100/100 de velocidad en PageSpeed Insights

Veamos ahora cuáles son estas diez reglas del informe de análisis, con una pequeña explicación de su significado, antes de pasar a ver cómo resolverlos en la próxima sección:

  • Eliminar el JavaScript y CSS bloqueante. La parte más importante de una página web es su parte superior (“above-the-fold”), que es la que aparece en pantalla nada más cargarse la página y lo primero que ve el usuario. Por tanto, es crucial que el navegador la muestre lo antes posible y no haya ningún recurso que retrase su visualización.
  • Especificar caché de navegador. Generalmente, una página web no cambia con mucha frecuencia, por lo que accesos repetidos de un usuario a una misma página descargaría los mismos recursos una y otra vez. Con la caché, el navegador guarda una copia de estos recursos, por lo que no necesitan descargarse continuamente.
  • Evita los redireccionamientos a páginas de destino. Un redireccionamiento transforma una dirección web en otra, lo que puede alargar el tiempo de conexión con el servidor y empezar a descargar la página.
  • Habilitar compresión. Los servidores y navegadores modernos soportan y reconocen la comprensión gzip, que puede reducir considerablemente el tamaño de los recursos y, en consecuencia, el tiempo de descarga de una página web.
  • Minificar CSS. Habitualmente, las hojas de estilo CSS están organizadas para facilitar su lectura por personas: sangrado, líneas en blanco, comentarios, etc. Sin embargo, toda esta información adicional y estructura no aportan nada a los estilos de la página web, aunque sí que aumenta el tamaño del fichero y su tiempo de descarga y procesamiento por el navegador.
  • Minificar HTML. Por la misma razón que las hojas CSS, los ficheros HTML suelen incluir información adicional para facilitar su lectura por las personas, pero innecesario para que sean interpretados y renderizados por los navegadores.
  • Minificar JavaScript. Lo mismo que lo visto para hojas CSS y códigos HTML, pero referidos a los ficheros JavaScript utilizados en la página web.
  • Optimizar imágenes. Con diferencia, las imágenes son el recurso que más ancho de banda consumen y más tiempo de descarga necesitan. Debemos procurar que las dimensiones y tamaño de las imágenes sean los menores posibles sin merma de su calidad en la visualización final.
  • Prioriza el contenido visible. Consiste en que toda o gran parte de la información que muestra en la parte superior visible de la página (“above-the-fold”) esté disponible lo antes posible, de forma que se pueda visualizar en el navegador aunque el resto de la página siga cargándose.
  • Reducir el tiempo de respuesta del servidor. El factor sobre el que menos control podremos tener, mide cuánto tarda el servidor de alojamiento en responder las peticiones de una página web u otro recurso desde un navegador.

 

Resolución de las reglas de rendimiento de PageSpeed Insights

La mayor parte de las recomendaciones que veremos a partir de ahora para resolver los incumplimientos de estas reglas son válidas y aplicables para cualquier plataforma con servidores Apache y cualquier gestor de contenidos, aunque dada la prevalencia de WordPress en la construcción de sitios web y blogs, cuando haya alguna herramienta o plugin que pueda resolver, en parte o en su totalidad, una incidencia, también la incluiré.

Tened en cuenta que no siempre hay soluciones directas, sino que dependen de cómo esté construido el sitio web; por ejemplo, en el caso de WordPress, el theme que utilice o los plugins que tenga instalados. De hecho, este aspecto es tan importante que puede haber themes o plugins que impidan la aplicación de algunas de las soluciones que aquí os propongo, especialmente cuando involucran plugins.

 

Eliminar el JavaScript y CSS bloqueantes del renderizado

Normalmente, una página web ocupa bastante más que la pantalla sobre la que se visualiza. Cuando una página se carga, lo primero que se muestra es su parte superior (“above-the-fold”), aunque el resto de la página siga descargándose desde el servidor:

Es prioritario que la parte superior de la página se cargue antes que el resto

Lo ideal sería que el navegador pudiera renderizar la parte visible de la página sin tener que esperar a que se cargue el resto de la página. Para ello, necesita dos cosas:

  • Que todo el contenido de esa parte esté disponible lo antes posible (este punto lo veremos en profundidad en su regla correspondiente).
  • Que no haya ningún código JavaScript o estilo CSS que postergue (bloquee) el renderizado hasta que se haya cargado casi toda la página.

Los estilos CSS determinan cómo se visualizarán los elementos de la página (como los colores, tipos de letra, estructura de la página, ordenación de los elementos, etc), mientras que el código JavaScript puede influir en el cómo y el qué se visualizará.

Por tanto, si uno u otro no están disponibles al empezar a cargar la página, el navegador deberá esperar hasta que lo estén para renderizarla y mostrarla. Si estuvieran al final de la página, o en servidores externos, el usuario tendría que esperar a que se descargasen todos para empezar a ver la página.

Salvo que tenga conocimientos bastante avanzados de programación JavaScript y estilos CSS, en circunstancias normales, un blogger o propietario autónomo de un sitio web no puede resolver una infracción a esta regla por sí mismo, pues depende casi exclusivamente de dos factores:

  • Cómo esté diseñado el sitio web a lo hora de utilizar códigos JavaScript y estilos CSS (es decir, en función del theme utilizado).
  • Los plugins o complementos que tenga instalados, puesto que pueden añadir códigos JavaScript o estilos CSS al diseño de las páginas web.

Pero no hay que perder la esperanza, pues aún podemos llevar a cabo acciones que minimicen el impacto del incumplimiento de esta regla, teniendo en cuenta que no siempre es posible eliminarlo por completo:

  • Si utilizamos un diseño web a medida, pidiendo al diseñador que el sitio web no incluya JavaScript ni CSS bloqueantes.
  • Si utilizamos un theme, eligiendo aquél cuyos diseñadores garanticen un impacto mínimo en este sentido (prácticamente cualquier theme moderno ya cumple este requisito).
  • Si utilizamos plugins o complementos, decidiendo si realmente son necesarios y, en caso afirmativo, buscando un plugin alternativo menos agresivo con esta regla.
  • Si utilizamos plugins o complementos, no utilizándolos en la parte superior de las páginas web, de forma que ésta pueda renderizarse sin necesidad de utilizar los recursos del plugin.
  • Si utilizamos un theme o plugins, contratando un diseñador web que los revise y reescriba para eliminar o reducir los elementos bloqueantes.

Para sitios web WordPress, una posible solución sería utilizar un plugin que concatene los ficheros JavaScript y las hojas CSS (por ejemplo, Autoptimize), de forma que de varios ficheros bloqueantes pasaríamos a uno solo.

Sin embargo, esta concatenación no preserva las dependencias entre plugins (hasta donde yo sé, ningún plugin puede y sólo se puede hacer manualmente), por lo que quizás no nos funcione inicialmente pero puede que, quitando algún plugin, funcione perfectamente: razón de más para reducir todo lo posible el número de plugins.

Por otro lado, debemos hacernos a la idea de que pocas veces podremos satisfacer esta regla al 100%, y nos debemos contentar con procurar que el impacto sea el menor posible; principalmente, haciendo un uso inteligente y crítico de los plugins.

 

Especificar caché de navegador

La caché de navegador acelera la renderización de las páginas
Caché para almacenar los recursos web

Contrariamente a la anterior regla, que pocas veces podremos resolver totalmente, esta regla casi siempre la podremos solucionar… salvo que utilicemos recursos externos (es decir, alojados en otros servidores). E incluso en este caso hay soluciones, aunque ya son específicas del recurso y servidor externos utilizados.

Google recomienda que el tiempo mínimo del caché de navegador sea de una semana, ampliándolo a un año para recursos estáticos (como imágenes) o que raramente cambian.

Este tiempo se puede configurar en el servidor de alojamiento, modificando un fichero de sistema denominado “.htaccess”. Normalmente, los proveedores de hosting permiten acceder y modificar este fichero, por lo que podemos hacerlo nosotros mismos (y si no lo permitiese, acudid a su soporte técnico).

¡¡¡ MUCHO CUIDADO !!! Un error en este fichero puede bloquear o tumbar un sitio web, por lo que siempre tengamos una copia de seguridad a mano por si nos equivocamos y podamos restaurarlo rápidamente.

Para configurar el tiempo mínimo del caché navegador a una semana, basta añadir las siguientes líneas al “.htaccess” (asegúrate de copiarlo exactamente como está):

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 week"
</IfModule>

Si queréis especificar distintos tiempos de caché según el tipo de recurso, una posible solución sería la siguiente:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/x-icon "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresDefault "access plus 1 week"
</IfModule>

Con este código, se configura una caché de un año para recursos de imagen, un mes para ficheros JavaScript y estilos CSS, y una semana para todo lo demás.

Además del tiempo de caché, el servidor también puede informar al navegador de la última vez que un recurso se modificó. De esta forma, aunque el recurso haya caducado en la caché, el navegador puede comprobar si ha sido modificado en el servidor y, en caso negativo, no hace falta descargarlo de nuevo. Para ello, basta añadir la siguiente línea al “.htaccess”:

FileETag MTime Size

No hay que olvidar que estas soluciones solo se pueden aplicar en nuestros propios servidores de alojamiento. Si nuestra página web también utiliza recursos externos, almacenados en otros servidores, no tenemos forma de modificar sus ficheros “.htaccess”, por lo que estamos sometidos a lo que sus respectivos propietarios quieran. Aún en estos casos puede hacer una solución, pero serían soluciones a medida para ese recurso y ese servidor.

Esto ocurre, por ejemplo, con el fichero “analytics.js”, necesario para poder utilizar los informes estadísticos de Google Analytics, que tiene un tiempo de caché en el servidor de origen de tan solo dos horas. Mediante una pequeña “artimaña”, aquí podéis ver cómo he podido sortear la limitación del tiempo de caché de navegador del script analytics.js.

 

Evita los redireccionamientos a páginas de destino

¿Cuando necesitamos hacer redirección de páginas web?
Con una redirección, cargas otra página

No puedo recordar la última vez que vi una infracción de este tipo. Con esto quiero decir que no son habituales y, por lo general, si la tenemos es porque nosotros mismos hemos añadido una redirección, supuestamente por alguna buena razón; por ejemplo, reestructuración del sitio web y no queramos perder el ranking de los antiguos enlaces.

Cuando hay una causa justificada, no deberíamos quitar los redireccionamientos, puesto que aseguran que el usuario llegue a una página web que sea de su interés en vez, quizás, a una página 404 de error, con mayor riesgo de que el usuario se vaya. Esta situación se puede presentar, por ejemplo, cuando el usuario llega a través de un enlace externo que apuntaba a una página anterior a la reestructuración del sitio web.

Pero lo que sí debemos procurar es que la navegación dentro de nuestro sitio web no tenga redireccionamientos; es decir, que todos los enlaces internos entre nuestras páginas web sean directos. Si cambiamos la estructura de nuestro sitio web, esto puede suponer una ardua tarea (revisar cada enlace de cada página y sustituirlo por el correcto donde sea oportuno), pero nos aseguramos que la navegación sea más rápida y fluida.

 

Habilitar compresión

La mayoría de los servidores y navegadores modernos soportan un tipo de compresión de datos en formato “gzip” o, en su defecto, “deflate”, de forma que toda la comunicación entre ellos (HTML, JavaScript, CSS, imágenes, ficheros, etc.) se haga con datos comprimidos en uno de estos formatos.

Al reducir de esta forma el tamaño de los datos intercambiados entre servidor y navegador, su tiempo de descarga también disminuye, con lo que la página completa también se descargará más rápido y se mostrará antes en el navegador.

En servidores apache, la configuración del servidor para hacerlo es tan sencilla como copiar el siguiente fragmento de código, para formato GZIP:

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

O el siguiente fragmento de código para el formato DEFLATE:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/xml application/xhtml+xml application/rss+xml application/x-httpd-php application/x-httpd-fastphp image/svg+xml
</IfModule>

Observad que en ambos casos se debe indicar qué tipo de recursos se van a comprimir, en nomenclatura “MIME”. He puesto la configuración más habitual, pero si queréis incluir otros recursos, podéis consultar su tipo MIME en el manual del servidor Apache.

Si no sabéis qué formato de compresión tiene instalado vuestro servidor, preguntad al soporte técnico de vuestro proveedor o probad vosotros mismos con uno y otro, comprobando con PageSpeed Insights cuando hay compresión. En el caso de que ambos estén disponibles, GZIP en general ofrece mejores resultados que DEFLATE.

 

Minificar HTML,CSS y JavaScript

Cómo minificar los ficheros de recursos HTML, CSS y JavaScript (JS)
Ficheros de recursos que podemos minificar

Aunque son tres reglas distintas, están tan relacionadas y su resolución es tan similar, que las vamos a ver conjuntamente.

Las páginas web se generan a partir del código de tres tipos de ficheros: los ficheros con código HTML, los ficheros con código JavaScript y las hojas de estilo CSS. Estos tres ficheros determinan qué contenido se muestra y cómo, ya sea textual o gráfico, imágenes incluidas.

Normalmente, cuando los diseñadores y desarrolladores web escriben estos ficheros, utilizan un formato fácil de leer para las personas, puesto que lo tienen que editar continuamente y deben ser capaces de localizar rápida y fácilmente cualquier punto del código para modificarlo o corregirlo. Esto significa que el fichero de código:

  • Incluye comentarios para explicar, diferenciar o separar porciones del código.
  • Está sangrado con espacios y tabulaciones para estructurarlo según su funcionalidad.
  • Incluye uno o más saltos de línea para separar las instrucciones entre sí.

Toda esta información, aunque útil para el técnico humano, no aportan nada a la representación final de la página web. Sin embargo, ocupan espacio dentro del fichero, aumentando su tamaño y, en consecuencia, necesitando más tiempo para descargarse y más tiempo de proceso del navegador para renderizar la página.

Con esta regla, PageSpeed Insights comprueba que estos ficheros de recursos no contengan este tipo de información, sino sólo código procesable por el navegador, con la consiguiente mejora de velocidad.

Tenemos tres formas de minificar estos ficheros:

  1. Utilizando los ficheros minificados que suministra PageSpeed, copiándolos en nuestro servidor en sustitución de los nuestros. Esta opción suele ser válida para ficheros JavaScript y estilos CSS, pero no para el código HTML generado por el gestor de contenidos.
  2. Utilizando nosotros mismos una herramienta de minificación con todos y cada uno de los ficheros, repitiéndolo cuando modifiquemos uno de ellos.
  3. Utilizando un plugin o complemento que lo haga automáticamente cuando uno de los ficheros de código se descargue. Personalmente, prefiero esta opción.

En WordPress, disponemos de dos plugins, el ya mencionado Autoptimize y Better WordPress Minify, que realizan automáticamente esta minificación. Además, ambos incorporan una caché para no minificar de nuevo un fichero de recurso que ya ha sido minificado previamente, con el consiguiente beneficio para el tiempo de proceso del servidor, que no deberá repetir esa minificación.

 

Optimizar imágenes

Resultado sorprendente lo mucho que esta regla se incumple. No sólo por la facilidad y rapidez con que se puede resolver, sino porque incluso el propio PageSpeed Insights suministra un fichero con las imágenes ya optimizadas, por lo que en último extremo lo único que tenemos que hacer es descargarlo y poner esas imágenes en nuestro servidor (aunque no sería la solución ideal).

La solución ideal comprendería los pasos siguientes:

  1. Ajustar las dimensiones de las imágenes a las dimensiones del lugar donde se mostrarán. Es decir, que imagen y lugar tengan el mismo ancho y altura. Toda imagen que sea mayor que su lugar de visualización supondrá un desperdicio de ancho de banda para descargarla.
  2. Comprimir las imágenes con baja pérdida de calidad (“lossy compression”) en vez de sin pérdida de calidad (“lossless compression”). La mayoría de usuarios apenas apreciarán la diferencia entre una y otra, pero el tamaño del fichero disminuye sensiblemente.
  3. Si necesitas proporcionar imágenes de alta calidad (por ejemplo, sitios de fotografía profesional), utiliza imágenes comprimidas para el carrusel o muestrario de fotos, con un enlace para descargar cada foto en alta calidad.

Aunque WordPress dispone de plugins que comprimen las imágenes, incluidas aquellas que el propio gestor de contenidos genera en diseños responsivos, sigue siendo nuestra responsabilidad ajustar correctamente sus dimensiones (por ejemplo, con la herramienta picresize). Si prefieres comprimir las imágenes tú mismo, en vez de utilizar plugins, la mejor herramienta online que he encontrado es kraken.

Por último, os dejo este enlace para quienes estéis interesados en optimizar al máximo la descarga de imágenes en WordPress, mientras que en este artículo podéis ver cómo comprimir imágenes en WordPress sin utilizar plugins.

 

Priorizar el contenido visible

El contenido "above-the-fold" debe cargarse lo antes posible
La parte superior de la página es la más importante porque es la primera en verse

El objetivo de esta regla es que el contenido de la parte superior de la página (“above-the-fold”) esté disponible cuanto antes, de forma que el navegador pueda renderizarlo sin tener que conectar varias veces con el servidor y aunque el resto de la página web no se haya descargado todavía.

Ya hablamos en la primera regla (“Eliminar el JavaScript y CSS bloqueantes”) de la importancia de la parte superior de la página y de cómo el diseño y desarrollo de la página web debe facilitar su renderizado sin necesidad de descargar la página completa y todos sus recursos asociados (incluidos ficheros JavaScript y hojas CSS).

Pero además de eliminar el JavaScript y CSS bloqueantes, debemos organizar el contenido de la página web para:

  1. Descargar en el menor tiempo posible todo el contenido de la parte superior. Esto significa que debemos procurar que todos los elementos que se visualizan en ella ocupen el menor tamaño posible (especialmente, las imágenes).
  2. Evitar que en la parte superior se muestre contenido dinámico, ya sea proporcionado por terceros (por ejemplo, los últimos mensajes de una red social) o propios mediante un widget (por ejemplo, los últimos posts de nuestro blog), puesto que requieren conexiones adicionales para descargarse, con el consiguiente retardo.

Esta reorganización también puede incluir las hojas de estilo CSS. El fichero de estilos debe descargarse por completo antes de empezar a renderizar la página. Si este fichero fuese muy grande, retrasaría el renderizado de la parte superior, aunque sólo utilizara un pequeño número de estilos.

En este caso, la solución sería extraer el código CSS utilizado por el contenido de la parte superior e introducirlo directamente dentro (“inline CSS”) de la página. Existen plugins (el Autoptimize que ha hemos comentado) y herramientas que pueden ayudar a identificar y extraer el CSS de la parte superior de  la página, pero solo los recomiendo para quien tenga suficientes conocimientos de CSS, pues pueden producirse conflictos y dependencias que deberán resolverse una a una.

Como podéis ver, al igual que ocurría con los códigos bloqueantes del renderizado, las soluciones para los incumplimientos de esta regla no están habitualmente en manos de un bloguero o un propietario autónomo de un sitio web, sino que deberá confiar en una diseñador o desarrollador web para solventarlo.

 

Reducir el tiempo de respuesta del servidor

Un buen tiempo de respuesta del servidor mejora el posicionamiento SEO
Un servidor de Hosting rápido para tu sitio web

Esta regla mide cuánto tiempo tarda nuestro servidor de alojamiento en responder a una petición. Google establece como valor idóneo un tiempo de respuesta inferior a 200 milisegundos (2 décimas de segundo, el tiempo en que Usain Bolt recorre 2 metros 😉 ).

Poco podemos hacer, como propietarios de un sitio web, para reducir este tiempo de respuesta, siendo responsabilidad casi absoluta del proveedor de alojamiento, que deberá proporcionarnos un buen servicio.

Si utilizamos WordPress (u otro gestor de contenidos), debemos elegir un theme (o equivalente) que esté respaldado por un buen equipo de diseñadores y desarrolladores. Esta es la única forma de asegurarnos que no incurrirán en malas prácticas que penalicen el tiempo de respuesta del servidor. Igual consideración debemos tener si contratamos un equipo para diseñar y desarrollar nuestra web a medida.

Por otro lado, no esperemos conseguir buenos resultados en esta regla si confiamos en proveedores de hosting “low-cost” o gratuitos: son baratos (o gratis) por algo. Además, en caso de algún problema, el soporte técnico suele ser lento e ineficaz (o, simplemente, no existe o debe contratarse aparte).

Contratar en un buen proveedor de alojamiento no es un gasto, sino una inversión y una garantía. En este aspecto, he tenido experiencia con varios proveedores, tanto para mi web como para otras webs profesionales, y el mejor resultado los he obtenido con WebEmpresa y Raiola Networks, en ambos casos con un soporte técnico rápido y eficaz, que me atendían y resolvían cualquier incidencia o duda en cuestión de minutos, y que os recomiendo sin dudarlo. En los siguientes enlaces podéis consultar su oferta de servicios, con descuento especial del 20%:

Raiola NetWorks: alojamiento WordPress

 

En el caso de WebEmpresa, debes indicar el código “cupon20” para acogerte a tu descuento:

WebEmpresa: alojamiento 100% WordPress

 

Conclusiones

Aunque existen muchas herramientas de diagnóstico para evaluar el rendimiento de un sitio web, para realizar cualquier mejora u optimización el informe debemos centrarnos en el informe de evaluación de PageSpeed Insights de Google.

Lejos de ser la más completa o más detallada herramienta de diagnóstico, Google la utiliza como factor de posicionamiento orgánico de los sitios web. Por tanto, nuestra prioridad pasa por resolver al menos las incidencias negativas de este informe (en color rojo) y, en la medida de lo posible, la mayoría de los avisos (en color naranja).

El informe de PageSpeed consta de diez reglas, pero se podrían distribuir en tres grandes grupos, en función del grado de complejidad de su resolución y del perfil técnico necesario para solucionarlos:

  • Requiere necesariamente un servicio externo: Tiempo de respuesta del servidor (uno de las reglas que más negativamente puede penalizar nuestro posicionamiento).
  • Requiere conocimientos técnicos relativamente avanzados (o contratar un servicio técnico externo): Eliminar el JavaScript y CSS bloqueantes del renderizado, Priorizar el contenido visible.
  • Requiere conocimientos técnicos básicos: Especificar caché de navegador, Evita los redireccionamiento a páginas de destino, Habilitar comprensión, Minificar HTML, CSS y JavaScript (mediante plugins), Optimizar imágenes.

Con estas consideraciones, nuestra estrategia de optimización del rendimiento de un sitio web comprendería los siguientes pasos:

  1. Contratar un servidor de alojamiento fiable, de calidad y un soporte técnico rápido y eficaz. Es decir, nada de alojamientos gratuitos o precios ridículamente bajos.
  2. Construir un sitio web, o elegir un theme de WordPress, que priorice adecuadamente el contenido visible y elimine el JavaScript y CSS bloqueantes. Puesto que solucionarlo a posteriori, con el sitio web ya construido, puede ser muy difícil o inviable.
  3. Reducir el número de plugins o complementos en el gestor de contenidos, puesto que tienden a incluir ficheros JavaScript y estilos CSS que pueden producir incidencias en las reglas relalacionadas.
  4. Asegurarse de cumplir, siempre, las reglas que no requieran conocimientos técnicos avanzados, e incluirlos en nuestras buenas prácticas de mantenimiento del sitio web.

 

Los problemas del informe de Google PageSpeed Insights requieren a veces analizar y hacer muchas pruebas hasta conseguir solucionarlos. ¿Qué estrategia sigues tú para resolverlos? ¿Utilizas alguna otra herramienta de diagnóstico para identificar las causas de los problemas? ¿Cuáles?

Imágenes: freepik, iconfinder, elaboración propia.

 

¿El post te ha resultado útil? ¡Ayúdame a mejorar y puntúalo!

[ Hasta ahora habéis votado 5, con nota media 4.6 ]
 
Tweet about this on Twitter0Share on Facebook0Share on Google+1Pin on Pinterest0Share on LinkedIn0Buffer this pageEmail this to someone

Quizás también te interese...

Problemas del Informe de PageSpeed Insights: Cómo resolverlos
Etiquetas: hosting    optimización    pagespeed    rendimiento
Sobre el autor,
Consultor SEO Freelance, Ingeniero Superior de Informática, Certificado en Google Adwords y Experto Universitario de Social Media Marketing, con más de 20 años de experiencia en el sector de Internet y las Nuevas Tecnologías.

Hay 1 comentario acerca de:
    “Problemas del Informe de PageSpeed Insights: Cómo resolverlos

Deja un comentario

Tu dirección de correo electrónico no será publicada.