A principios de año, Google anunció a través de su blog oficial Webmaster Central que la velocidad de carga móvil empezaría a ser un factor de rankeo para resultados de búsquedas móviles a partir del 1 de julio de 2018.

La velocidad de carga existía como señal dentro del algoritmo desde 2010, pero sólo para resultados en desktop. En cuanto a los resultados en móvil, hasta ahora Google únicamente había tenido en cuenta a la hora de rankear que fueran “mobile friendly”, pero no había usado (hasta julio de 2018) la velocidad de carga para determinar qué resultados móviles debían mostrarse primero.

El anuncio oficial contenía 3 avisos y una recomendación muy interesantes de cara al SEO:

  • Sólo afectará a las páginas más lentas y a un pequeño porcentaje de las consultas
  • Se aplicarán los mismos criterios a todas las páginas, independientemente de la tecnología con la que se hayan diseñado
  • La intención de búsqueda seguirá siendo un factor muy importante, así que una página lenta podrá tener una buena posición si ofrece contenido pertinente y de calidad

Luego hablaré de estos puntos más en detalle, sobre todo de la recomendación y las métricas.

Y ahora que ya estamos en julio, ¿qué ha pasado con la actualización de velocidad?

Llegado el 9 de julio, Google actualizó el post original de enero, añadiendo el aviso de que el “Speed update”, como ellos mismos llaman a este update, ya estaba poniéndose en marcha “para todos los usuarios”.

Curiosidad: el post en el blog Webmaster Central en español, publicado originalmente el 18 de abril, también ha sido actualizado, pero al hacerlo se han confundido con la fecha, y en lugar de constar como actualizado el 9 de julio, el post dice que ha sido actualizado el 18 de abril, misma fecha de su publicación.

Ejemplos de páginas afectadas por el Speed Update

El primer ejemplo de una página “tocada” por el update de velocidad lo mostró en Twitter Glenn Gabe (este hombre debe tener acceso a varios miles de perfiles de Analytics, en todos los updates ve los efectos él antes que nadie).

Parece que hay poco duda, porque Gabe asegura que el tráfico orgánico en desktop se mantiene estable, mientras que el orgánico en móvil baja entre la semana del 9 de julio y la del 15.

Junto a esto, vemos unas métricas en Lighthouse que son un poema, sobre todo las de Speed Index y Time To Interactive (dos de esas métricas user-centric que Google nos recomienda usar para medir el rendimiento de nuestras páginas): 14 segundos y 42 segundos respectivamente.

Una página con esos valores para un dispositivo de gama media en 3G (que son los que da Lighthouse) no es que sea lenta, es que prácticamente imposible de usar. Hit del Speed Update bien merecido, por tanto.

En base a esto, el ejemplo de Glenn Gabe da poca información sobre el umbral en el que una página empieza a verse afectada por el nuevo update. En otras palabras, ¿qué considera Google las páginas más lentas y cómo se traduce eso a las métricas que están al alcance de cualquiera?

Me refiero sobre todo a FCP y DCL, las métricas que Google muestra también desde enero de 2018 en Pagespeed Insights y que salen de ese mismo documento sobre métricas centradas en el usuario.

Mis ejemplos: un sitio lento que sí ha sido afectado por el update

No estoy ni remotamente cerca del número de perfiles de Analytics a los que tiene acceso Glenn Gabe, pero a una treintena sí que puedo acceder (y a sus respectivas cuentas de Search Console). Seguro que entre ellos podría encontrar uno que mostrase ese patrón de caída de tráfico orgánico, sólo para móvil, entre el 9 y el 16 de julio.

Y lo encontré. Se trata de un blog al que se le hizo un diseño responsive en 2014 y desde entonces no se ha tocado en ningún aspecto.

Cuatro años son muchos en desarrollo web y en expectativas de los usuarios. Lo que era rápido (o al menos aceptable) en 2014 no lo es, ni mucho menos, ahora.

Lo curioso es que a raíz del cambio a responsive, y sobre todo a partir del famoso mobilegeddon del 21 de abril de 2015, el sitio empezó a recibir un buen volumen de orgánico desde móvil, y así se había mantenido hasta julio de 2018, a pesar de ser un sitio claramente lento (ahora veremos cuánto). Prueba bastante clara de que hasta ahora Google no había usado la velocidad de carga en móvil.

Así hasta el día 13 de julio, donde las principales landing pages orgánicas entran en un bache en cuanto a tráfico móvil, pero se mantienen estables en desktop.

Las gráficas, en Analytics y Search Console, para que no haya duda:

analytics caida trafico organico speed update

caida trafico organico movil speed update google

trafico organico estable desktop speed update google

Bien. ¿Cómo de lentas, exactamente, son las páginas afectadas?

Vamos a verlo en Pagespeed Insights y en Lighthouse.

Primero, la puntuación de Pagespeed Insights ya deja claro que Google considera esta página como francamente lenta en móvil.

No sólo asigna un clarísimo SLOW a las medianas de su FCP y DCL, sino que además, la comparación con el resto de páginas presentes en el Chrome UX Report es sonrojante:

pagespeed insights metricas 100 tercio lento

Nota: si te estás perdiendo un poco con todas estas siglas, ve corriendo a leer mi post sobre FCP y DCL en Pagespeed Insights. En él te aclaro qué son, qué mide cada una y cómo usarlas.

Pero este es un caso tan extremo, casi en la línea del ejemplo de Glenn Gabe, que decidí buscar más páginas en el mismo blog, en busca de una que hubiera sido afectada también, pero que mostrase unas métricas un poco más decentes.

Por ejemplo esta:

PageSpeed Insights metricas de sitio afectado por speed update google

De nuevo vemos una situación francamente mala en cuanto a FCP / DCL, si bien esta vez algunas de las cargas están en el tercio medio.

Con todo esto, queda claro que a Google se le puede aplicar lo de que “el que avisa, no es traidor”. Incluso la puntuación de “Optimización”, que no está basada en métricas reales de tiempo de carga, sino en el grado de cumplimiento o no de una serie de normas generales, está en la zona roja o de suspenso (para Pagespeed Insights todo lo que esté por debajo de 60 es calificado de SLOW, de 60 a 84 es AVERAGE y de 85 a 100 es GOOD).

Y las reglas que no se cumplen tampoco dejan muchas dudas sobre los problemas en los que se iba a meter la página con el Speed Update. Sobre todo el tiempo de respuesta del servidor y los recursos que bloquean el renderizado son lo que rompen la página:

Las estadísticas muestran que la página mediana de Internet necesita 4 ciclos de ida y vuelta por el bloqueo del renderizado y aproximadamente 75 recursos (1 MB) para cargarse. PSI calcula que esta página necesita 3 ciclos de ida y vuelta por el bloqueo del renderizado y aproximadamente 129 recursos (0,7 MB) para cargarse. Cuantos menos ciclos de ida y vuelta y bytes necesite una página, más rápida será.

Sugerencias de optimización

Reducir el tiempo de respuesta del servidor

En nuestro test, el servidor respondió en 1,2 segundos (el tiempo recomendado por Google es 0,2 segundos o menos)

Eliminar el JavaScript que bloquea la visualización y el CSS del contenido de la mitad superior de la página

Tu página tiene 10 recursos de secuencias de comandos y 20 recursos CSS que provocan un bloqueo

Aprovechar el almacenamiento en caché del navegador

Optimizar imágenes

Optimizar estas imágenes para reducir su tamaño en 67,9 KB (reducción del 42 %).

Pero volviendo a las métricas puras y duras, las que podemos poner en décimas y segundos, queda el análisis con Lighthouse.

Por no alargarlo, fijaos en Speed Index y Time To Interactive, las que se iban a tiempos estratosféricos en la página de ejemplo de Glenn Gabe:

lighthouse pagina afectada por speed update google

Más adelante os contaré algo sobre el tráfico de esta segunda página, que ha bajado en móvil en las mismas fechas (entre el 9 y 16 de julio), pero en un porcentaje menor que la primera – y no es simplemente por tener unas métricas un poco mejores.

Lo que importa por el momento es que con este segundo ejemplo ya tenemos una posible línea divisoria para marcar el límite, no tan extrema como la que salía del tuit de Glenn Gabe.

Ahora falta encontrar una página que, siendo casi tan lenta como esta, pero sin llegar a tanto, no haya sido afectada por el update de velocidad de julio. ¿La tendré entre mis Analytics?

Mis ejemplos: un sitio lento, pero no tanto, que no ha sido afectado (por ahora)

Pues sí. Buscando, buscando, encontré un buen candidato. Se trata de otro sitio con diseño responsive, pero que lleva años sin tocar en cuanto a WPO. Vamos directos a su Pagespeed:

PageSpeed Insights metricas de sitio no afectado por speed update google

Aquí ya vemos una situación menos negra (o roja), ya que la mediana del DCL (DOM Content Loaded) consigue colarse entre los valores medios de la muestra, y de hecho el total de los usuarios que tienen cargas lentas en cuanto a DCL no llegan a ser la mayoría, como en los anteriores ejemplos.

Es cierto que el FCP sí está en problemas, pero tener un 59% de cargas en el tercio lento, no es tan grave como tener un 90%.

Veamos ahora lo que dice Lighthouse (recordemos, simulando una carga con dispositivo móvil de gama media en 3G):

lighthouse pagina no afectada por speed update

Conclusión: esta página, sin ser un prodigio de velocidad de carga, se salva (por ahora) de perder tráfico móvil con el update.

Pero no puedo estar del todo tranquilo con el alto tiempo de Time To Interactive (momento en el que el usuario puede interactuar con la totalidad del contenido de la página), y debo seguir trabajando mi FCP, a pesar de lo que diga Lighthouse, ya que los datos del Chrome UX Report muestran que la mayoría de mis usuarios reales están viendo el primer contenido en 3 segundos o más.

Por último, ¿qué me enseña todo esto respecto a qué webs están destinadas a caer en el speed update de julio y cuáles no?

Como habrás visto, es muy difícil establecer un valor en una métrica concreta, por debajo del cual estás a salvo de perder tráfico móvil. Yo prefiero quedarme, como indicador más fiable, con el porcentaje de cargas de usuarios reales “en rojo” que nos da Pagespeed Insights.

Si tus cargas en el tercio lento están por debajo del 50% para ambas métricas, creo que es casi seguro que estarás a salvo del update.

Pero es posible (al menos por ahora) tener un porcentaje más alto de cargas lentas, e incluso valores peores en métricas individuales que los que hemos visto para el último ejemplo, y no haber perdido tráfico y posiciones en móvil.

¿Por qué? Porque no todo depende del tiempo de carga.

Las excepciones a la regla dentro del update de velocidad

Volvamos a una de las advertencias que daba Google en su anuncio de enero de 2018:

La intención de búsqueda seguirá siendo un factor muy importante, así que una página lenta podrá tener una buena posición si ofrece contenido pertinente y de calidad

¿Recuerdas que te dije que mi segundo ejemplo, el que tenía unas métricas de tiempo de carga ligeramente mejores que otras páginas del mismo sitio, mostraba algo curioso en su tráfico?

Su caída no era tan pronunciada como la de las demás páginas del sitio.

A primera vista, podría ser por esos tiempos de carga ligeramente mejores, y de hecho es un factor que no podemos descartar del todo. Pero si miramos en Search Console su tráfico segmentando por búsquedas, encontramos algo muy interesante:

Hay búsquedas que no se han visto afectadas para nada. Su tráfico orgánico desde móvil sigue igual, estable. Mientras que hay otras búsquedas que sí bajan en cuanto a orgánico móvil, y esas son las responsables de la pérdida de tráfico de esta url.

search console posicion estable update velocidad google

search console posicion no estable update velocidad google

¿Qué tienen de diferente las búsquedas que se mantienen estables?

Si eres lector habitual de este blog, seguro que ya lo sabes: el CTR. Las que se mantienen estables son búsquedas en los que la página tiene una posición Top1 estable, y con un CTR muy alto.

Estamos hablando de una query genérica de dos palabras (no es búsqueda de marca) con un 52% de CTR para móvil (muy alto) y una posición Top1 totalmente estable a lo largo de los últimos 3 meses. Para esta query y esta página, es como si el Speed Update no hubiera existido.

Como expliqué en mi post sobre el update de marzo de 2018, un CTR especialmente alto ( claramente por encima del 35% y siempre que la búsqueda no sea de marca o de navgación) parece ser un indicador para Google de que no necesita mover ese resultado, digan lo que sigan los demás factores. Lo cual coincide con lo que se decía en el anuncio oficial de enero de 2018.

Conclusión: ¿Qué puedo hacer para librarme del update?

Espero no haberte mareado con siglas y datos de distintas fuentes. Realmente, la conclusión de este análisis para mí es muy sencilla.

Sabemos desde hace mucho tiempo que Google viene insistiendo en la velocidad de carga, y últimamente más aún con la velocidad de carga móvil. Lo que hace 3 años era aceptable, ya no lo es hoy, y lo que hoy pasa el corte, puede que ya no lo haga en 6 meses.

Usa las herramientas que Google pone a tu disposición, tanto Pagespeed Insights con sus nuevas métricas obtenidas del Chrome UX Report, como Lighthouse, que te puede dar un nivel de análisis en cuanto a WPO sin igual en otra herramienta gratuita.

Haz todo lo posible por cumplir las reglas y mejorar en cuanto a las principales métricas (FCP, DCL, Speed Index y Time To Interactive). Hazlo no sólo por Google, sino ante todo por tus usuarios.

Es cierto que, por el momento, este update ha afectado sólo a un porcentaje bajo de páginas, las más lentas en cuanto a carga móvil de las que actualmente están rankeando en Google, y para algunas páginas sólo lo ha hecho en determinadas búsquedas.

Ya hemos visto que, en algunos casos, con valores relativamente altos según estas herramientas, puedes haberte librado (por ahora) de la caída de tráfico móvil entre el 9 y 16 de julio que ha traído este update.

También hemos visto que incluso con valores muy malos, puedes quedarte donde estabas en algunas búsquedas, si tu resultado cumple a la perfección la intención del usuario para esa query concreta.

Pero si estás en uno de esos últimos casos, yo no me quedaría tranquilo. Trabajaría para optimizar lo más posible, porque no podemos descartar que este update vaya en oleadas, y que haya una segunda oleada que tarde o temprano sí haga volcar el orgánico móvil de tu página.

En cualquier caso, si quieres un indicador casi seguro de si estás en problemas, usa este:

Si las distribuciones de carga de las páginas en Pagespeed Insights muestran porcentajes por encima del 80% en rojo, SEGURO que estás o vas a estar muy pronto en problemas.

Y si Pagespeed Insights no muestra estos valores por falta de datos, haz un análisis rápido con Lighthouse y si todos tus valores del apartado Performance están en naranja o rojo, casi seguro que estás en problemas también.

PD: Próximamente publicaré un vídeo-post en profundidad sobre cómo hacer una auditoría compelta de WPO con Lighthouse. Por ahora, te deseo que el Speed Update no te haya tratado demasiado mal y te permita disfrutar de agosto tranquilo. 😉