Google Speed Update: ¿Cómo afecta al SEO el update de velocidad móvil?

Por Juan González Villa

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. ;)

Suscríbete a mi newsletter semanal (a veces quincenal) ;)

* indicates required

Consentimiento (obligatorio)

El responsable de recoger y guardar estos datos que me das voluntariamente es un servidor, Juan González Villa, con la única finalidad de informarte con nuevos posts en mi blog, eventos profesionales y enviarte mi newsletter.

Tienes derecho a cancelar tu suscripción en cualquier momento y puedes ejercer tu derecho a rectificar o solicitar eliminación de tus datos, tal y como se recoge en la Política de Privacidad.

Utilizamos Mailchimp como nuestra plataforma de marketing. Al hacer clic a continuación para suscribirse, reconoces que tu información será transferida a Mailchimp para su procesamiento. Obtenga más información sobre las prácticas de privacidad de Mailchimp aquí.

11 comentarios en “Google Speed Update: ¿Cómo afecta al SEO el update de velocidad móvil?”

  1. Me queda embobado con tu análisis Juan,

    No conocía la extensión de Chrome Lighthouse, siempre uso Page Speed, Gtmetrix, Pingdom Tolls o Webpagetest, la probará y comparare a ver que tal.

    Como dices en el post, tampoco no me fío de Google e intentaría siempre independientemente del sector o el posicionamiento de la web optimizar al máximo cada página, aunque la respuesta del usuario sea magnífica y Google no tenga tanto en cuenta en ese caso la velocidad, al final tendrá en cuenta que has de seguir sus reglas.

    Te pongo una recomendación al post desde mi artículo de estadísticas del mes de Julio como favorito ;)

    Un saludo

    • Muchas gracia por tu comentario, Jose, y por incluirme en tu recopilación de julio. Lighthouse tiene algunas funciones extra que nos te vana dar Pingdom, GTMetrix, etc. La primera vez que haces una auditoría con ella te quedas un poco abrumado de la cantidad de información que da y las métricas que usa, pero una vez que te acostumbres verás que sacas un montón de cosas útiles. Yo todavía le estoy sacando todo su jugo; en breve compartiré las cosas más importantes en un vídeo post.

  2. Enhorabuena por el articulo. Acabo de pasar el Lighthouse y en principio parece que no me da malos datos, pero no se interpretarlos muy bien. Gracias por toda la información

    • Gracias a ti por comentar, Jose! Si no ves demasiado rojo en el Lighthouse, en principio eso es bueno, pero recuerda que optimizar el tiempo de carga no es algo que debas hacer sólo por evitar perder tráfico en un update de Google, sino para tener contentos a tus usuarios, que es lo más importante. ;-) Saludos!

  3. Gran post Juan. Con algunas plantillas es un dolor de cabeza, ya que aunque tengamos configurada la versión AMP, uno de los errores que marca Pagespeed es la carga asíncrona y no siempre es posible de solucionar. Con algunas plantillas, si utilizas preloader y cargas los scripts que te señalan de forma asíncrona, no pasa del preloader. Esperemos que se vayan adaptando los desarrolladores ya que a mi me ha pasado con plantillas top tipo Júpiter y Btheme…

    • Muchas gracias! Efectivamente, a veces hasta las mejores plantillas crean tantos problemas como los que te solucionan. No se puede poner una a ciegas y olvidarse, hay que tener en cuenta todas estas cosas. El diseño y la posibilidad de personalizar son importantes, sí, pero la velocidad de carga también debe pasar a ser uno de los factores más importantes a la hora de decidirse por un theme u otro. Y no lo digo sólo porque Google se ponga exigente, sino porque cuanto más rápido cargue nuestro WP, mejor para nuestros usuarios. Saludos!

  4. Buen artículo :) Veo que además te aplicas bien el cuento y tienes la página puntuado genial en google page speed.

    ¿Divi + Wp Rocket con alguna configuración en especial o la ma´gia surge por si sola? Me gustaría probarlo en alguno de mis micronichos para ver si mejora la velocidad y con ella el posicionamiento :)

    Saludotes!

    • Hola, Josean, gracias por tu comentario. WP Rocket ayuda casi de manera automática a que cualquier WP vaya más rápido, sea cual sea la plantilla. Pero cuando tienes Divi, que es pesada y usa muchos recursos aunqeu no es de las peores que te puedes encontrar, hay que hilar un poco más fino.

      En mi caso ayuda mucho que tengo el blog alojado en un servidor NGINX en lugar del clásico Apache, tal y como explico en mi post sobre mejorar respuesta del servidor. Pero no sólo eso, sino que para optimizar más aun el tiempo de carga he prescindido de botones para compartir en redes sociales y cualquier llamada a las APIs de Twitter y Facebook, que ralentizan mucho, y también he limitado mucho el uso de fonts. Aun así, me queda un paso extra, que sería quitar todo el CSS que no se está usando (está en mi lista de To Do desde hace un tiempo).

      Moraleja: la gente suele decir que Divi es muy lenta y un desastre para el SEO, pero si la tienes en el servidor correcto, con un WP Rocket bien configurado, y eliminas todos aquellos recursos que realmente no necesitas, puedes tener un Divi casi tan rápido o igual que la plantilla más ligera del mercado (y sin perder las ventajas de Divi). Saludos!

  5. Buenas!

    Si, Divi-Avada-Newspaper son themes muy conocidos y buenos, pero algo pesados en realidad. Disculpa si te cotilleo la web es defecto profesional, pero veo que a pesar de tenerla muy bien optimizada (felicidades nuevamente) y de no tener publicidad para que sea liviana, las últimas actualizaciones no te han beneficiado ¿sabes a qué se debe?

    – Web con contenido de calidad
    – Buena velocidad de carga
    – Sin publicidad

    Sinceramente, no lo entiendo ¿?

    • Supongo que lo dirás por los datos de Sistrix o Ahrefs. La verdad es que mi trafico a lo largo de agosto ha seguido más o menos igual que en el mes anterior. Un -3% en el orgánico, pero pensando que es mes de vacaciones y que no he publicado nada en todo el mes, creo que es lo normal.

      Hombre, si Ahrefs / Sistrix muestran algo de bajada casi seguro será por una pérdida de posiciones en alguna keyword de bastante volumen (tipo bajar del 9 al 15), pero eso sería algo que antes en el fondo no me daba tráfico real, o apenas. En las keywords que sí me dan tráfico no ha habido cambios importantes, al menos hasta ahora. Y si ha habido algún cambio con el update de agosto, más bien ha sido lo contrario, ya que he empezado a recibir algunos clics e impresiones por nuevas longtails, según veo en Search Console (y se puede ver en Ahrefs también). Saludos!

Los comentarios están cerrados.