My Authors
Read all threads
Hoy os voy a hablar del WPO en el SEO.

Dos mundos que pueden ir muy de la mano pero donde hay mucha cosas que se confunden y mezclan provocando recomendaciones SEO absurdas en muchos casos.

Un spoiler: El WPO no es SEO ni afecta a los rankigns casi nunca.

¡Dentro hilo!
Antes de que los defensores del WPO (Web Performance Optimizatoin, aka "que mi web vaya más rápido") me salten al cuello, diré que el WPO me parece un área muy necesaria en muchos negocios y que es una parte vital de la experiencia de usuario. Un negocio rápido gusta y vende más.
Pero este hilo va de SEO, de mejorar tus resultados en el buscador y ahí si tu web va más o menos rápida, o si tiene una puntuación de pagespeed alta o baja, no tiene porque importarle un carajo al buscador.

Es un depende, pero con más casos en el negativo que en el positivo.
Para ser más claro, voy a dividir la afectación a los resultados que puede provocar la velocidad de tu site en el SEO en dos partes:

1. ¿Afecta a tus rankings? ¿Las webs más rápidas posicionan mejor?

2. ¿Afecta a tu crawling? ¿Las webs más rápidas se rastrean y crawlean más?
1) Titular: Pequeños cambios en tu velocidad no van a afectar a tus rankings.

Google lo ha negado varias veces y es realmente complicado encontrar una causalidad directa entre mejoras de carga y posiciones (también pq suelen acompañarse con más cambios).

Ahora os explico....
Existen recomendaciones sobre la velocidad por parte de Google e incluso un Update dedicado a móviles llamado "Google Speed Update" a medidados de 2018.

Os dejo un post de @seostratega sobre GSU con una buena síntesis y ejemplos que puso en su día.

useo.es/google-speed-u…
Pero al final la afectación a los rankings solo sucede si te ponen la bandera de "web muy lenta". En el resto de casos no afecta.

Esto podría cambiar pero de momento es así: Una web muy lenta puede ver como empeoran sus rankings. Una normal no los mejora por pasar a ser rápida.
Para más señas estos comentarios de Muller que resaltamos en su día en el @MinisterioSeo (programa que debes seguir sí o si):

seroundtable.com/google-speed-g…

Lo importante de la noticia no es que algún día pueda existir un grado de velocidad, sino que ahora mismo no lo hay...
Nota: Cuando intentamos entender el algoritmo de Google Search es importante separar que partes de los criterios son evaluados granularmente ( una puntuación de lo bueno que eres en eso ) de las que son más simples y solo actúan solo "banderas" o "checks" que los tienes o no.
En resumen sobre el punto (1)

- Cuidado con las webs lentas, te puedes ir a los infiernos de google.

- No pienses que por ganar unos milisegundos vas a tener mejores posiciones.

Vamos por el punto (2)
2) ¿La velocidad afecta al rastreo e indexación de google?

La respuesta corta aquí sería: ¡Sí, como no iba a hacerlo!

La larga entra en que no toda la velocidad de carga importa y en que en muchos negocios no tienes que preocuparte por esas cosas...
Ahora vamos a dividir la velocidad de carga en dos partes:

- Respuesta del servidor: Que medimos con el famoso Time To First Byte (TTFB) o con el Tiempo de carga del HTML.

- Carga total: La que percibe el usuario y donde entrarían GPS o las nuevas métricas de Lighthouse.
Aquí es donde muchos se confunden.

Lo que más importa al usuario (y forma parte de su experiencia) es la carga total. Un site puede devolver el HTML en un instante que si el usuario no percibe el contenido no sirve para nada.

Pero y a Google, al rastrear ¿qué le importa?
Para saberlo debemos entender cómo rastrea Google y todo el tema que hay detrás de las 2 olas de indexación.

Google puede renderizar (interpretar y visualizar) tu html pero tiene una forma peculiar de hacerlo. Lo hace en 2 oleadas muy separadas en el tiempo.
En primera ola Google solo recoge HTML por lo que la velocidad del servidor es lo único que le importa (no va a ver CSS, ni JS, ni tus imágenes y vídeos).

En la segunda ola (que ocurre solo con indexadas) recoge recursos (y no todos) para renderizar y poder verlo todo.
Aquí os dejo un gráfico de como funciona eso de las olas que de en una charla del seoplus en 2018 y os dejo link a la charlita.

(quedaros con el link que vuelvo a hablar de otra cosa de esa charla ahora mismo)

es.slideshare.net/ikhuerta/mitos…
Bien, pues resulta que esa Segunda Ola, gracias al descubrimiento de nuestro amigo @Errioxa de que Google usa "referral" al pedir recursos para renderizar más o menos podemos medirla analizando los logs del servidor.

En el link de la charla anterior veréis detalles sobre esto.
Desde entonces hemos avanzado mucho en todo esto y para nosotros en IKAUE ya es normal, al analizar logs, dividir las peticiones en hits reales vs recursos de renderizado.

¿Sabeis cuantas páginas renderiza Google en tu site?
¡Un moco! Así os lo digo.
Os pego dos capturas de render de un site (que además no es de los de render más bajos)

Poco más de un 1% de peticiones de renderizado. Solo ciertos bots se encargan de renderizar y solo sobre las páginas indexadas más importantes.
¿Significa todo esto que Google no sabe si una página es lenta por JS o Imágenes?

No, las páginas importantes si las carga, pero es que además tiene los datos de Chrome (que veis en google pagespeed) para saber si tu web es lenta.

¡Pero es que estabamos hablando de crawling!
A nivel de crawling lo dicho, el tiempo de rastreo que provoca el total de tus recursos para ver la página es irrisorio, así que en crawling lo que realmente lo que nos importa es el el tiempo de servidor, lo demás es bueno para el usuario, pero no afecta a tu indexación.
Y ahí esta nuestro problema. Como SEOs no solemos tener control de código de la web ni de sistemas. Y resulta que esas partes son las que importan de cara a optimizar el crawl budget de tu site.

Podemos hacer una primera criba para evitar rastreos innecesarios pero luego...
Lo primero: Analiza si tienes problemas de rastreo con Google. Sobretodo si para ti el crawl budget es un limitante.

Si tu site es pequeño (solo unos cientos o miles de urls) casi seguro que no lo será. En esos casos limpia la porquería pero no te preocupes tanto de tiempos.
Y si lo es, deja a Javascript y a las imágenes en paz.

Tienes dos problemas que atacar: El TTFB y el tiempo de carga del HTML.
El tiempo de carga del HTML es fácil de arreglar.

- Reduce etiquetas
- Minimiza código
- Comprime el envío

Hay mucha info por internet sobre esto....
Pero el problema suele estar en el TTFB. Ahí podemos recomendar caché, cambios en el código etc, pero es una lucha de los programadores. Nosotros podemos ser los ogros y no pasar ni una.

Y seamos serios el tiempo para una web bien optimizada en TTFB es de muy pocos milisegundos
Y no olvidemos que hay otras partes en la carga. La resolución de DNS, el Peering y demás temas de sistemas.

Ya puedes hacer un master acelerado si te toca lidiar con eso.... :)

Se puede, pero al final pretendemos saber más que alguien que se dedica a ello y metemos la gamba
Pero resumiendo (que me estoy acercando demasiado al lado técnico)

A lo que voy es a que hacer un buen WPO es bueno, pero no tiene sentido que el SEO empuje muchas veces en acciones como meter sprites CSS, pasar a Http2, mejorar la carga del JS, etc, etc, etc....
Podemos encontrar acciones con mucho impacto trabajando el WPO de sites con un mal performance. Podemos arreglar problemas de crawlbudget (si los hay) con una rápida respuesta del servidor y un uso inteligente de las cachés. ¡Y puede irnos genial!
Pero no necesitamos engordar la lista de tareas SEO (que seguro que ya es larga) con acciones de 0 impacto en el negocio.

Prioricemos lo que nos va a traer tráfico y evitemos las mierdiptimizaciones. ;)
Y Cierro ya el hilo. Espero haberos hecho pensar un poco en el tema.

No convenceré a los fanáticos del WPO, ya lo se, pero quería dejaros todo esto por aquí.

Buenas tardes!
Añado 1 comentario, que ya van 4 privados sobre el tema 😁

Sí, las gráficas sobre render las sacamos de los logs.

No son ninguna herramienta comercial. Es un desarrolo que hacemos en IKAUE sobre los logs para obtener esos datos (ya sabeis: Logs > Google Big Query > Modelado)
Y aprovecho el hilo para mencionar el tema del momento y la campaña que se está haciendo de recaudación de fondos con #vamostalegon

Tenemos una cita el próximo día 30 para sacarle una sonrisa a este gran hombre! >> vamostalegon.com 😊
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Iñaki Huerta

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!