Estoy totalmente de acuerdo. Mi búsqueda rápida no fue el punto y, desde luego, no pretendía ser ningún tipo de prueba autorizada; y cuando la publiqué, tampoco hice tales afirmaciones. Solo hice una pregunta basada en los resultados de mi búsqueda. Debería haber cerrado sesión antes de realizar la búsqueda, porque cuando cierro sesión, obtengo los mismos resultados de “falta de” información, jaja.
El único “punto técnico tangible” que he hecho realmente es que Google ha declarado públicamente que comenzará a utilizar LCP (y otras métricas de Core Web Vitals) a partir de mayo de 2021.
También planteé el argumento empresarial de que Google no puede hacer declaraciones como esta y engañar a las personas. Sería un gran error para una gran empresa cotizada en bolsa. Mi suposición es que no están cometiendo tal error, y cuando Google dice que aún no está utilizando LCP como factor de clasificación, no tengo motivos para no creerles.
Si los autores bien intencionados que argumentan que LCP está afectando al SEO y que estaban seguros de “sus hallazgos”, y que abogan por que Discourse realice cambios estructurales en su código debido a esos “hallazgos”, tuvieran el código disponible para revisión, de código abierto, para que todos pudieran examinarlo, su “evidencia”, tras una revisión por pares, podría ser convincente.
Esto no es nada personal ni adversarial; de hecho, solo hemos visto algunos gráficos y ningún código, mientras que Google ha declarado públicamente que ni siquiera está utilizando LCP como factor de clasificación SEO en este momento.
En toda “justicia técnica”, en realidad no hemos visto ninguna “evidencia” de que Google esté utilizando LCP como factor de clasificación ahora. Es solo una suposición y no hay código que revisar ni someter a revisión por pares para respaldarlo.
Todos aquí nos gustaría saber qué cambios son necesarios para optimizar el SEO y aumentar los ingresos. Sin embargo, necesitamos hechos tangibles, código que podamos revisar, donde podamos convencernos de que Google está realmente utilizando LCP como factor de clasificación.
Google afirma que actualmente no está utilizando LCP como factor de clasificación y que comenzará a utilizarlo como factor de clasificación SEO en mayo de 2021. Hasta ahora, no hemos visto ninguna razón para dudar de lo que Google ha declarado públicamente; ni hemos visto ninguna “evidencia sólida revisada por pares” en contrario.
Así que, para todos aquellos que se quejaron de mayo de 2020, eso no fue nada comparado con lo que quizás venga en mayo de 2021. Quiero decir, también estás diciendo que las comunidades de Discourse PODRÍAN verse afectadas en términos de resultados de búsqueda el próximo año (ya veremos qué sucede).
Sí, estoy totalmente de acuerdo contigo y con todos aquí preocupados por LCP y el efecto que tendrán las Core Web Vitals de Google.
Además, elogié profundamente a todos los que están corriendo para intentar encontrar respuestas y soluciones ante este problema inminente.
En cuanto al colapso del SEO de mayo de 2020, esto también nos ocurrió a nosotros en servidores LAMP; por lo tanto, no es un problema de Discourse, en absoluto; y aún no conocemos los pasos exactos para solucionar este problema de mayo de 2020, porque si supiéramos qué arreglar, con un alto grado de confianza, todos podríamos “arreglar” y “ajustar”.
A lo largo de los años, todos hemos visto resultados muy extraños de la IA de Google y cómo la IA de Google clasifica el contenido y manipula los resultados de los SERP.
Mi punto anterior fue que me pareció infundado leer en este tema que alguien presionara al equipo Meta de Discourse para realizar cambios estructurales muy sustanciales en todo su ecosistema basándose en suposiciones y conjeturas, y no en hechos sólidos derivados de un código revisable.
Dicho esto, LCP será muy importante, de todos modos, en un abrir y cerrar de ojos.
Lo nuevo es que el LCP se captura desde los teléfonos Android de los usuarios. Android es la plataforma más lenta en la que operamos, y eso nos afecta de manera desproporcionada.
Lo que sugirió @sam también era servir esa vista para algunos usuarios anónimos mediante un plugin, pero no es algo que vayamos a hacer pronto.
Vale. Me falta conocimiento sobre cómo funciona exactamente (pero parece que aún hay algo de carga inicial que hacer, y podría ser más rápido. De ahí todo este tema). Esta discusión ya ocurrió en cierta medida el 14 de octubre, más arriba. Jeff mismo planteó la idea:
¿Por qué no tomar el contenido y crear un sitio estático totalmente pregenerado? Algo tan rápido como sea posible. Y enviar esto a los motores de búsqueda en lugar del foro real? La idea sería que el contenido es lo más importante aquí, no la experiencia. Y enfocarse en la rapidez de la entrega, ya que parece ser lo importante para los motores de búsqueda.
El desplazamiento infinito no ha sido culpado últimamente, pero crearías páginas estáticas pregeneradas sin desplazamiento infinito. Y las diseñarías como un coche de rally: te deshaces de cada gramo de peso que no sea estrictamente necesario. Sin menú hamburguesa, sin logotipo, sin avatar para los autores. Solo te enfocas en el contenido y en la velocidad.
Sería como un buen restaurante (=el foro de Discourse), donde montas un drive-in con pedidos para llevar. La misma gran comida (=el contenido) pero sin ninguna de las experiencias. Haces tu pedido en un altavoz al entrar (=tu búsqueda en el motor de búsqueda) y recibes tu comida precintada lanzada por tu ventana. Toda la idea es que es lo que se demanda, y solo la comida (=contenido) y la velocidad de entrega son importantes. Si a la gente le gusta la comida, quizás vuelvan y disfruten de toda la experiencia dentro.
Después, depende de cada propietario (=administrador) tomar una decisión: ¿Crees que un drive-in es malo para tu marca y te niegas a hacerlo, o sigues ese camino para atraer a más gente, sabiendo que muchos quizás nunca vengan a comer dentro (muchos ya no lo hacen, pero podría empeorar aún más. Y quizás tu restaurante parezca mucho menos agradable presentado de esa manera)? Pero quizás esa famosa web que recomienda restaurantes te envíe más gente (queda por ver si es efectivo).
Lo que se necesitaría es un plugin o módulo para generar estas páginas estáticas a medida que se agrega contenido al foro (imagino que no debería ser excesivamente complicado). Solo agregarías un enlace aquí y allá a tu foro real (configurado en “no rastrear” para los motores de búsqueda). Dependería de cada administrador usar esta solución o no.
Si lo que se ha dicho arriba es correcto en principio, y este problema podría empeorar en el futuro, esto parece una solución aceptable para mí. O quizás no entendí bien. (Nota: todo esto sería SOLO DE LECTURA, por supuesto)
Vale, pero lo que no termino de entender es que, en este caso, nadie lo hace mejor, ¿verdad? ¿Por qué afectaría a los resultados de búsqueda? Si los sitios de Discourse funcionan igual de bien (o igual de mal ) que los demás. ¿O no se abren también otros sitios en Android?
Android es más lento que el promedio en rendimiento de un solo núcleo, lo que afecta a aplicaciones de una sola página de gran peso como Discourse. Abordamos este tema en profundidad en El estado de JavaScript en Android en 2015 es… pobre
El iPhone más rápido es 10 veces más rápido que el último Pixel al renderizar Discourse. Google no tiene en cuenta los renderizados del iPhone en LCP, simplemente porque no pueden, ya que no existe un Chrome real en iOS.
Así que, de hecho, podría haber una ventaja en ese sentido al generar un sitio de “páginas pequeñas” para enviar a los motores de búsqueda. ¿No valdría la pena? (quizás no). ¿O los administradores deben ofrecer nuevos teléfonos de gama alta a sus usuarios? ¿Ese es el propósito de todos esos anuncios que dicen que has ganado el último iPhone?
Al ojear rápidamente esto Overview of CrUX | Chrome UX Report | Chrome for Developers, parece que Google obtiene la información espiando a los usuarios (con su permiso), por lo que tendrías que persuadir a muchos de ellos para que usen tu Discourse de bolsillo
Parece que estás confundiendo Ember con Ember CLI. Ember es el framework que ya estamos utilizando (y hemos estado usando durante más de 8 años). Ember CLI son las herramientas de línea de comandos a las que nos estamos migrando en lugar de usar el pipeline de activos de Rails. Lo menciono porque algunas de las cosas que dices (como que las versiones anteriores a la 3 requieren reescrituras) no serían ciertas para Ember CLI, pero podrían serlo para Ember.
De nuevo, Ember CLI no se encarga del renderizado. Eso lo hace Ember y, en ocasiones, tiene problemas de rendimiento. Ten en cuenta que esto no es algo específico de Ember; todos los frameworks actuales tienen trampas de rendimiento de las que debes ser consciente. Después de años trabajando con Ember, identificamos dos rutas críticas (la cabecera y la vista de temas) que necesitaban un mejor rendimiento y cambiamos a un enfoque basado en un DOM virtual.
Es posible que no siempre necesitemos hacer esto, dependiendo de cómo funcione Glimmer/Ember Octane, pero el código es bastante estable y ahora se ejecuta rápidamente incluso en dispositivos móviles antiguos.
Ember Octane se introdujo en la versión 3.15 y desde entonces ha habido dos lanzamientos LTS (3.16 y 3.21). Nos actualizaremos a él, pero de forma escalonada. Afortunadamente, el equipo de Ember permite activarlo opcionalmente (incluso por archivo) el formato que deseas utilizar.
Dicho todo esto, hay bastante que criticar sobre Ember. Cuando el rendimiento era un problema mayor para Discourse, hubo un par de versiones prometidas que terminaron perjudicándonos en lugar de ayudarnos. Fue difícil. Tuvimos que mantener un control muy estricto durante mucho tiempo para cumplir con nuestras necesidades.
Hoy en día, también tiene una fracción de la popularidad de frameworks más nuevos como React. Sin embargo, ¡React no existía hace 8 años! Nuestras únicas opciones eran Angular, Ember y Knockout. Si crees que actualizar Ember es difícil, deberías ver por lo que pasó Angular de la versión 1 a la 2 (sin mencionar sus desvíos con Dart).
Actualizar Ember a lo largo de los años ha supuesto mucho trabajo, ¡pero al menos es una opción! Ninguno de los otros frameworks ofrecía ningún tipo de ruta de actualización como esta.
En cuanto a reescribir en Vue/Next/React, creo que la gente subestima enormemente la cantidad de código que tenemos y que funciona perfectamente. Sería una cantidad de trabajo inimaginable.
Lo estoy considerando @justin y @awesomerobot, pero quería que Robin opinara primero sobre los detalles específicos de Ember CLI.
En su núcleo, hay un poco de “¿Qué sucede cuando una fuerza imparable se encuentra con un objeto inamovible?” paradoja aquí… somos intencionalmente una aplicación de JavaScript (o SPA), y eso implica compensaciones que decidimos hacer en 2012/2013 basándonos en nuestra mejor suposición de cómo sería el futuro en 2022/2023. Aunque obviamente tengo sesgos, diría que nuestra predicción de “bueno, el rendimiento de los navegadores en dispositivos móviles será indistinguible del rendimiento de los navegadores de escritorio” fue acertada.
¡Incluso, más allá de lo esperado, ya que la mayoría de los teléfonos Apple más recientes son más rápidos que las portátiles y los equipos de escritorio! Eso… ¡no lo vi venir!
Aunque seguiremos mejorando lo que podamos en cuanto a la velocidad de carga inicial y la velocidad en general, creo que nuestro historial en este aspecto es encomiable. Por un lado, obtuvimos tanta publicidad en 2015 que Google internamente realizó varias mejoras en V8, Chrome y Android para abordar el rendimiento débil de los SoC de Qualcomm medido en JavaScript.
Nuestro talón de Aquiles ha sido… Qualcomm. Lamentablemente, Qualcomm no ha tenido un buen desempeño en el frente del rendimiento hasta la fecha, ya que el dispositivo Android con mejor rendimiento está solo a nivel aproximado del iPhone 7. Tarda mucho en que los dispositivos Android más antiguos salgan del mercado, pero los 855 y 865 fueron ambos competentes, a un nivel aproximado del iPhone 7:
Tengo que desplazarme más hacia abajo para llegar a un dispositivo Apple que sea tan lento como el dispositivo Android más rápido, pero si lo hago, la coincidencia más cercana es el iPhone X / iPhone 8 con ~910 puntos en Geekbench. Desafortunadamente, el 865, por razones que no entiendo completamente, tiene un rendimiento ligeramente inferior en el lado web, por lo que seguimos a niveles de rendimiento del iPhone 7 en Speedometer:
Ojalá viviéramos en un mundo donde hubiera dispositivos Android que funcionaran con una variedad de SoC de diversas empresas que compitieran por construir los SoC más rápidos y potentes… Por otro lado, el rendimiento del iPhone 7 es sólido para Discourse y me alegra que eventualmente todos los dispositivos Android, incluso los antiguos, sean “al menos tan rápidos como un iPhone 7”. También tengo los dedos cruzados por el próximo Snapdragon 875; debería haber más detalles al respecto en los próximos meses.
Según los resultados de Geekbench 5, podemos ver que el Xiaomi Mi 11 está impulsado por el Snapdragon 875 de 5 nm (como insinuó nada menos que el ejecutivo de Xiaomi, Lu Weibing). El próximo Xiaomi Mi 11 ha logrado obtener 1.102 puntos en la prueba de núcleo único y 4.113 puntos en la prueba de múltiples núcleos.
Si es cierto, eso lo colocaría al nivel del A12, y ¡ojalá eso se manifieste también en el lado web!
De todos modos, hay una decisión arquitectónica fundamental aquí en Discourse de ser una aplicación de JavaScript… y estamos totalmente comprometidos con ese camino en el futuro previsible.
Para quienes están atentos a sus estadísticas, aquí tienen otra fecha para anotar. Será interesante ver qué sucede en las próximas semanas en relación con la última actualización principal de Google, la de diciembre de 2020.
¡No puedes olvidar los Mac con Apple Silicon anunciados recientemente!
Por curiosidad, ¿de dónde provenía esa publicidad?
El chip A10 todavía está aguantando por un hilo.
Por si acaso, estoy bajando mis expectativas. Apple siempre ha estado por delante.
Dicho esto, los smartphones Android todavía están intentando ponerse al día. Es absolutamente ridículo. Apple ya tiene el chip A14 y probablemente ahora esté trabajando en el A15 para el próximo año.
Gracias por compartir eso. Aquí hay algunos puntos relevantes de esta discusión que podemos extraer del artículo:
Qué hacer si te afecta. Google ha ofrecido consejos sobre qué considerar si tu sitio se ve negativamente afectado por una actualización principal en el pasado. No hay acciones específicas para recuperar el posicionamiento; de hecho, un impacto negativo en el ranking puede no indicar que haya algo mal en tus páginas. Sin embargo, Google ha proporcionado una lista de preguntas a considerar si tu sitio se ve afectado por una actualización principal. Google mencionó que puedes observar cierta recuperación entre actualizaciones principales, pero el cambio más significativo que verías ocurriría después de otra actualización principal.
En mi opinión, cuando hablamos de SEO, es decir, de optimizar los resultados de los motores de búsqueda en comparación con otros sitios, hablar del hardware del usuario es en gran medida irrelevante.
¿Por qué?
De hecho, es bastante sencillo.
Tomemos el caso de una persona y sus resultados de búsqueda en su dispositivo móvil.
Independientemente de la velocidad de su dispositivo o del chipset que tenga, el rendimiento será similar en todos los sitios web, porque la experiencia del usuario final (el rendimiento) de un único dispositivo en la red será, en su mayor parte, la misma en todos los sitios web de rendimiento comparable. Los sitios web más rápidos serán más rápidos y los más lentos serán más lentos, independientemente del chipset u otros componentes del dispositivo del usuario final. Una marea alta levanta todos los barcos y una marea baja los hunde a todos. En SEO, los dispositivos del usuario final son “ruido” como señal de SEO en comparación con la aplicación de servicio, que es lo que se optimiza en el “SEO”.
Por lo tanto, si un teléfono móvil es el más rápido de todo el universo, todos los sitios web serán rápidos (o lentos) dependiendo de la velocidad de la red y del diseño del sitio web. El enfoque del SEO está en optimizar la aplicación web y la entrega de dicha aplicación, no los dispositivos del usuario final. Si una aplicación web funciona “increíblemente bien” en un chipset, lo mismo ocurre con todos los demás sitios web de diseño similar. El enfoque del SEO no es el dispositivo del usuario final; es la optimización de la aplicación web, el contenido, el tiempo de carga basado en el servidor; no el dispositivo del cliente. Los dispositivos del cliente visitan, en teoría, todos los sitios web, por lo que todo ello es “ruido” en la relación señal-ruido del SEO.
Desde la perspectiva del SEO de un sitio web, la optimización para motores de búsqueda basada en la experiencia del usuario será la misma en toda la red para todos los usuarios de la misma clase (características de rendimiento) de todos los dispositivos móviles del usuario final. Lo único que dará a un sitio web una ventaja de SEO sobre otro será el rendimiento del sitio web (y de su red), no los dispositivos del usuario final.
¿Por qué?
Porque los dispositivos del usuario final funcionarán de la misma manera en todos los sitios web, en términos generales. Si el móvil del usuario es lento debido a la memoria o al chipset, será lento en todo el ciberuniverso de sitios web. En otras palabras, la discusión sobre cómo los dispositivos del usuario final afectan al SEO es inútil. La optimización para motores de búsqueda es una operación del lado del servidor, no del lado del cliente.
Lo que importa es el contenido, la presentación y el rendimiento; y cómo la IA de Google puntúa estos factores en todo el ciberuniverso. Si, por ejemplo, todo el mundo en el planeta actualiza a teléfonos móviles con computación cuántica, el SEO será el mismo porque todos los usuarios finales tendrán las mismas “curvas de rendimiento de dispositivos del usuario final”. La optimización ocurre en el proveedor (el sitio web). Del mismo modo, si todo el ciberuniverso se degrada a teléfonos móviles con chipset lento, los rankings de los motores de búsqueda serán en gran medida los mismos; porque la optimización que debe ocurrir la realizan los servidores que entregan el contenido web.
Por supuesto, Discourse, al ser una SPA impulsada por JavaScript, funcionará mejor después de cargar si los móviles son más rápidos. ¡Lo mismo ocurre con todos los demás sitios web! En general, lo que importa es el rendimiento de la red, así como el rendimiento del servidor, no el dispositivo del usuario final en lo que respecta al SEO. Esto no es una opinión mía, es un hecho científico y de ingeniería. Mi opinión o conexión emocional con JavaScript o EmberJS no cambia cómo funciona el SEO. Lo que funciona para el SEO es el contenido y el rendimiento de la aplicación web.
Para concluir, Google utiliza IA avanzada, principalmente redes neuronales artificiales, para determinar cómo clasifica e indexa el contenido web. La optimización para motores de búsqueda se basa en cómo la IA de Google clasifica el sitio, el rendimiento del sitio y el “atractivo del sitio para la IA de Google”. Cuánto amemos JavaScript, Ruby o Python, o cuánto nos guste o adoremos la elegancia y los mecanismos de cualquier aplicación web que proporcionemos a los usuarios finales, no es relevante; a menos que nuestra pasión por nuestra aplicación atraiga a la IA de Google y estemos creando contenido único que esté bien presentado a la IA de Google y cómo la IA de Google percibe el rendimiento; no cómo nosotros percibimos el rendimiento y el contenido.
Nosotros no clasificamos nuestros propios sitios web. La IA de Google es la que realiza la clasificación.
Como ha declarado públicamente Google:
“Una forma de entender cómo funciona una actualización principal es imaginar que hiciste una lista de las 100 mejores películas de 2015. Unos años después, en 2019, actualizas la lista. Naturalmente, cambiará. Algunas películas nuevas y maravillosas que nunca existieron antes ahora serán candidatas para su inclusión. También podrías reevaluar algunas películas y darte cuenta de que merecían un lugar más alto en la lista que el que tenían antes. La lista cambiará, y las películas que antes estaban más arriba y ahora bajan no son malas. Simplemente hay más películas que merecen estar por delante de ellas”, escribió Google.
La compañía ofreció la siguiente lista de preguntas a considerar al evaluar tu contenido:
¿Proporciona el contenido información original, reportajes, investigaciones o análisis?
¿Proporciona el contenido una descripción sustancial, completa o exhaustiva del tema?
¿Proporciona el contenido un análisis perspicaz o información interesante que vaya más allá de lo obvio?
Si el contenido se basa en otras fuentes, ¿evita simplemente copiar o reescribir esas fuentes y, en su lugar, aporta un valor y originalidad sustanciales adicionales?
¿El titular y/o el título de la página ofrecen un resumen descriptivo y útil del contenido?
¿El titular y/o el título de la página evitan ser exagerados o sensacionalistas?
¿Es este el tipo de página que querrías guardar en favoritos, compartir con un amigo o recomendar?
¿Esperarías ver este contenido en una revista impresa, una enciclopedia o un libro, o que fuera citado en ellos?
Esto es SEO y el negocio principal de Google es crear algoritmos para que las máquinas puedan puntuar y clasificar sitios web.
Esto es inconsistente con los registros: sabemos que Google está recopilando tiempos de carga de páginas del mundo real desde dispositivos Android y los está utilizando para el posicionamiento de las páginas.
Sí, pero todos los dispositivos Android (del mismo tipo) funcionan básicamente igual para todos los sitios web (del mismo tipo). En otras palabras, si optimizas un sitio web basado en JavaScript que utiliza webpacker y bundler, desde una perspectiva de SEO, estás compitiendo con todos los demás sitios que son SPAs en JavaScript que utilizan webpacker y bundler, etc.
No he dicho que Google no esté recopilando esta información. Estoy tratando de explicar que centrarse en el dispositivo del cliente no resolverá el problema de rendimiento SEO de las SPA. «Una marea alta levanta todos los barcos», por lo que una CPU más rápida que procese bien el JavaScript comprimido (rápida, optimizada, etc.) funcionará bien en todos los sitios web similares.
En otras palabras, el SEO está en el lado del servidor (como escribí arriba con mucho tiempo y detalle), no en el lado del cliente.
Esto está bien documentado, por cierto.
No importa :). Prefiero no debatir esto aquí en meta. Gracias.
Google ha sido muy claro sobre lo que consideran señales SEO importantes, ahora y hasta 2021. Rediseñarán constantemente su IA basándose en eventos y situaciones en el ciberespacio.
Desde una perspectiva de SEO, efectivamente compites con sitios que son técnicamente similares.
Pero desde una perspectiva empresarial, compites con otros sitios de tu mercado, independientemente de su tecnología. Y eso podría hacer que la gente considere cambiar a una tecnología que se percibe como “mejor” desde una perspectiva de SEO. Y es en esa situación en la que se encuentran algunas personas.
Quiero decir, también estás diciendo que las comunidades de Discourse PODRÍAN verse afectadas en términos de resultados de búsqueda el próximo año (ya veremos qué sucede).
Eso… ¡no lo vi venir!
Por otro lado, el rendimiento del iPhone 7 es sólido para Discourse y me alegra que eventualmente todos los dispositivos Android, incluso los antiguos, sean “al menos tan rápidos como un iPhone 7”. También tengo los dedos cruzados por el próximo Snapdragon 875; debería haber más detalles al respecto en los próximos meses. 
