Ayuda:Rendimiento de un wiki

Conforme la web (y los servicios y sitios que aloja) continúa creciendo y cambiando, las partes técnicas de los sitios como Fandom deben de cambiar para adaptarse a los hábitos de sus usuarios y mantenrse moderno. Para servicios de información como son los wikis, existe una infinidad de fuentes donde los fans pueden encontrar respuestas para casi cualquier tema.

Aunque nos encantaría imaginar que los fans pueden llegar instantáneamente a una comunidad de Fandom u otra con solo escribir una dirección web obvia, la realidad es que más del 80% de los visitantes llegan gracias a los resultados de los motores de búsqueda.^[1] En la mayor parte del mundo, Google provee de una plataforma casi exclusiva para toda búsqueda.^[2] Además, muchas de las búsquedas que llevan a wikis de Fandom no son "Wiki X", sino que suelen ser búsquedas sobre títulos y temas específicos. Esto representa un cambio en los hábitos de los usuarios que han evolucionado con la web, así como el fuerte impacto de los motores de búsqueda.

Con frecuencia, Google hace cambios a los algoritmos que controlan su servicio de búsqueda, y a veces anuncian los cambios de sus futuros planes. Tres de estos cambios^[3][4][5] se espera que impacten significativamente a Fandom en específico, debido a la naturaleza de cómo se desarrollan y editan los wikis. Estos cambios, si no se responde a ellos, reducirán la visibilidad tanto de wikis individuales como de Fandom como plataforma. Por lo tanto, esta guía hablará sobre cómo son vistos los wikis desde una perspectiva técnica (y humana), y qué pueden hacer las comunidades para adaptarse.

Métricas

Hay varios factores que determinan el rendimiento de un wiki, y cada paso en el proceso tiene distintas métricas.

Rendimiento de MediaWiki

Antes de que el wikitexto de una página encuentre su camino en la web, esta página tiene que convertirse en HTML. El proceso de procesamiento y visualización toma lugar en el software del servidor MediaWiki, donde se traduce capa-a-capa hasta el lenguaje básico de las páginas web. La velocidad a la que se procesan y presentan no suele demorar más de 2 segundos, y si la página no ha sido modificada, la presentación de la página puede ser acelerada gracias a un proceso conocido como "cacheo".

El rendimiento de una página MediaWiki se mide en los recursos de tiempo y memoria que necesita para presentar una página, así como cuan complejo es el HTML resultante (ya que los navegadores deben de interpretar el código HTML y convertirlo en algo que los humanos puedan entender visualmente). Las páginas que toman información de otras partes del servidor (un proceso conocido como "transclusión") toman más tiempo y recursos. Usar plantillas es una forma de transclusión, por lo que la complejidad y profundidad de anidamiento de las plantillas afecta al rendimiento. Dependiendo de cómo estén creadas, esto también puede aplicarse a extensiones que mueven contenido de una página a otra (como las listas de páginas dinámicas o DPL).

Core Web Vitals

Traducido como Signos vitales esenciales de la web^[6], desde hace tiempo Google pone especial atención a tres indicadores clave de rendimiento que afectan a la relevancia. Estos son:

• Despliegue del contenido más extenso (Largest Contentful Paint; LCP). Mide el rendimiento de la carga, o qué tan rápido el área de contenido más grande está visible para el lector.
• Demora de la primera entrada (First Input Delay; FID). Mide la interactividad, o qué tan rápido se pueden pulsar los enlaces y elementos de formularios.
• Cambio acumulativo del diseño (Cumulative Layout Shift; CLS). Mide la estabilidad visual, o cuánto se mueven los elementos visibles inicialmente en la pantalla antes de que se pueda interactuar con ellos.

Mucho de lo que miden los Core Web Vitals depende en la distribución de las páginas que realiza Fandom, aunque hay acciones de los editores y comunidades que puedn mejorar los signos vitales de un wiki. Aunque es importante tener esto en cuenta para la vista de escritorio, gran parte de la preocupación de Google se concentra en la vista de móviles para usuarios que no han iniciado sesión. Para algunos propósitos, Google considera a los wikis individualmente al determinar su relevancia; sin embargo, también considera todo Fandom como un único bloque en algunas situaciones. Los Core Web Vitals tienen un mayor efecto en la plataforma como una sola pieza (y por ende puede beneficiar a los wikis pequeños que no suelen ser buscados), pero siguen siendo importantes para los wikis idnividuales, y es importante conocerlos y hacer los cambios pertinentes.

Contenido entendible y extenso

Tener las páginas de tu wiki fáciles de encontrar son factores importantes para el rendimiento, más que unas simple métricas.

Partes importantes del algoritmo de Google incluyen "Passage Ranking" e "indizado total de páginas". Google toca cada página que encuentra a través de los enlaces en las páginas y mapea sutilmente mientras realiza copias en su base de datos, la cual procesa para obtener información. Esta información incluye a google leyendo oraciones (a través del índice que creó) y "entendiendo" su contexto — por ejemplo, si una página dice (en una oración completa) que "X es la madre de Y" y otra página dice que "Z es el padre de X", Google modela efectivamente en su "mente" que "Z es el abuelo de Y" sin que haya sido escrito explícitamente. Este proceso de semántica ayuda a Google a encontrar respuestas para las preguntas de los usuarios cuando buscan información. Mientras que los motores de búsqueda arcaicos dependían en gran manera de las palabras clave de una página, Passage Ranking es sobre usar el lenguaje natural y los datos disponibles (como tablas e infoboxes) para desarrollar modelos de manera que Google sepa el lugar correcto al que enviar a los usuarios. Por esto es que tener más contexto y narrativa (incluso si esto lleva a páginas más largas) ayuda a construir un concepto más completo que Google puede referenciar. No es una coincidencia que este método sea también mejor para que los humanos puedan entender el tema de un wiki, porque varios de los métodos de Google están diseñados para imitar cómo piensan los humanos — si Google entiende lo que dice una página, predice que esta página será el mejor recurso para que los humanos entiendan la página (y otras en el mismo wiki), por lo que le dará una relevancia mejor.

Estas extensas páginas pueden medirse según cuánta información tienen. Tener páginas dispersas con pocas referencias al contenido es más útil para sitios orientados a actuar como bases de datos que para wikis de Fandom, donde los usuarios están más interesados en la opinión y sabiduría de la comunidad en lugar de meros hechos. La experiencia de una comunidad al dividir temas auto-contenidos desde artículos largos o combinar artículos pequeños relacionados es una métrica importante que no es fácil de medir.

Experiencia del usuario

Los lectores no se quedarán si se les ahuyenta. Tener páginas que sobrepongan información densa o difícil de manejar hará que los usuarios busquen otro lugar igual que harían páginas mal escritas o de mala calidad.

Google mide la experiencia del usuario sistemáticamente de varias maneras. Objetivamente, Google puede rastrear cuánto tiempo se invierte en una página y, a través de un análisis, construir un modelo de cómo experimentan los usuarios el contenido de la página. Google también puede usar Calificadores de Calidad humanos para verificar qué tan efectivo es el algoritmo para enviar a los usuarios al lugar correcto. Estos calificadores hacen opiniones profesionales sobre cuán útil y usable es un recurso, lo que puede afectar indirectamente a la relevancia cuando el algoritmo de Google es ajustado a partir de sus reportes.

Sin embargo, la métrica más efectiva de experiencia del usuario comienza por cuán fácil o difícil es operar una página &mdas; específicamente si el contenido es fácil de entender e interactuar con él desde dispositivos móviles. Toda la estilización y opciones de interacción añadidas a una página no compensan una mala organización o material mal redactado; esto puede afectar a la experiencia del usuario peor si buscan información específica pero no pueden atravesar su interfaz o encontrar los paneles ocultos.

Arreglos prácticos

Hay varias maneras prácticas de mejorar el rendimiento de un wiki como editores. En su mayoría, son hábitos para reconsiderar, en parte porque la naturaleza de la web ha cambiado comparado con cuando los wikis aparecieron por primera vez. Cada uno de estos tiene pequeños efectos, pero en conjunto contribuyen a un mejor posicionamiento del wiki para un mejor rendimiento.

Contenido original y esbozos

Aunque hay herramientas de MediaWiki para automatizar e interpretar los aspectos técnicos de las páginas, como su longitud y conexión a través de enlaces, estas herramientas no identifican esbozos o contenido superficial. Los esbozos son un término tradicional usado en los wikis para referirse a páginas que han sido manualmente marcadas como incompletas y necesitan más información. El contenido superficial es cuando una página no responde a las preguntas que un usuario podría estar buscando. Por lo tanto, muchos esbozos también son considerados como contenido superficial, incluso si no todas las páginas cortas son esbozos. Los wikis de Fandom actualmente no son penalizados por tener un gran número de contenido superficial, aunque hay evidencia de que los algoritmos de google asumen cosas sobre un wiki (o todo Fandom) cuando encuentra patrones de contenido superficial, y puede actuar en el futuro basándose en ello.

Las páginas cortas tienen problemas vitales, pero los esbozos tienen además problemas de comprensión y experiencia del usuario. Por ejemplo, las páginas cortas tienen pocas áreas de contenido; muchas veces tan pequeñas que los encabezados y barras de herramientas se vuelven áreas más grandes en comparación. Como resultado, las áreas de contenido pequeñas son desplazadas más por cosas como barras de herramientas, y tienen una puntuación más alta y peor de CLS. Debido a su naturaleza de interactividad, los encabezados y barras de herramientas cargan más lento que el contenido; si son el área más grande de la página (en tamaño del HTML, no su tamaño visual) y tardan más en cargar, las puntuaciones de LCP y FID están por debajo de los valores ideales.

Los esbozos, debido a que no responden a preguntas más profundas por su naturaleza superficial, tienden a considerarse menos relevantes por Google. Tener una proporción significativa de esbozos contra artículos completos reducirá la confianza general que tiene Google de que un wiki responda a una pregunta, y por lo tanto posicionará peor a sus páginas (incluso si no son esbozos). Por ende, es mejor eliminar los esbozos tan pronto como sea posible (en un lapso de 30 días, cuando se espera que Google re-indice un wiki), ya sea borrando la página, añadiendo información o fusionándola con una página relacionada. Puede ser útil recordar que los humanos piensan de la misma manera, y prefieren ver información reducida como parte de una imagen más grande en lugar de algo incompleto y aislado. Tener secciones de páginas vacías, especialmente secciones de introducción vacías, tiene un efecto negativo tanto en el procesador de Google como en la experiencia del usuario, ya que tal vacío representa un final del camino en lugar de una oportunidad de seguir avanzando.

Los enlaces rojos (o enlaces a páginas que todavía no existen) eran vistos como oportunidades para los editores y potenciales editores para construir nuevas páginas de contenido. Aunque existen opiniones distintas sobre cuán efectivos eran para atraer editores, los enlaces rojos dañan los Core Web Vitals y el indizado; es por esto que los enlaces rojos se muestran como texto normales en la experiencia móvil y sin haber iniciado sesión. Los enlaces rojos dirigen a los rastreadores automáticos de contenido a áreas que no existen, contando como un error cuando una página no pude ser encontrada. El conteo total de errores encontrados en un sitio web, independientemente de si es un wiki o no, reduce su credibilidad y confianza percibidas. Reducir tu número total de enlaces rojos puede mejorar rápidamnte el rendimiento y posicionamiento.

Las páginas de categorías normalmente son algo sobre lo que se piensa después en los wikis. Se puntúan tan alto como las páginas de artículos si el modelo de Google las considera así de relevantes, debido a la información inferida. Cuando no hay introducciones o contexto, aparecen en los resultados de Google como texto incomprensible. Cada categoría debería de tener al menos algún texto en el área de contenido de la página.

Páginas robustas y usabilidad móvil

Un malentendido común sobre la división del contenido es cuando los artículos se dividen en segmentos usando pestañas (usando enlaces en la parte superior de la página, o usando pestañas interactivas). Con estos enlaces a otras páginas — un proceso al cual Fandom se refiere como "navgación con pestañas de página" — inconscientemente se crean o implican contenidos incompletos. Distribuir la información necesaria para entender qué es un único concepto de artículo (personaje, episodio, arma, etcétera; también conocido como entidad de contenido), dividiéndolo en múltiples páginas, hace más difícil para Google crear el modelo de dicho concepto. De manera similar, los lectores humanos tienden menos a visitar y leer múltiples páginas para entender facetas individuales de un mismo elemento. Este efecto suele conocerse como "la princesa está en otro castillo", porque el usuario tiene que recorrer distintos enlaces para encontrar lo que busca, siguiendo el aroma de la información en una persecusión de lo que realmente quiere saber.

Tener una "imagen completa" donde el usuario espera encontrarla y tener una explicación extensa y detallada de cada aspecto individual en una página separada no es algo malo. Una página "general" (también conocida como "página base", porque es el título sin subpáginas) debería de incluir al menos lo esencial necesario para entender el concepto del artículo. Los enlaces en el cuerpo del texto (quizá usando plantillas de {{Artículo principal}} o {{Véase también}}) debajo de los encabezados de secciones) pueden llevar al usuario a la información más extensa y detallada que busca, especialmente si se combina con un resumen y una explicación del contexto. Por ejemplo, en una página con "Biografía" e "Historia" como enlaces en la parte superior, ¿cómo podría el usuario saber qué información hay en cada página? De esta manera, todos los artículos involucrados pueden y deben de ser ideas completas por sí mismas y no fragmentos que hay que reunir.

Hay que notar que si tales pestañas son creadas usando plantillas o JavaScript para un diseño enfocado en la vista de escritorio, podrían no funcionar correctamente en dispositivos móviles. Estos enlaces no tienen ninguna relevancia en los intereses semánticos de Google (el contexto no se entiende y parecen sólo enlaces huérfanos a la deriva en la parte superior del texto del artículo). En lugar de añadir algo que no se ve ni funciona bien o no aparece para la mayoría de lectores, colocar enlaces navegacionales en un segmento de <navigation> de una infobox producirá un puente que los usuarios móviles y motores de búsqueda pueden entender mejor.

En este modelo, no hay mucha distinción entre los "enlaces con forma de pestaña" en la parte superior de la página y "enlaces con forma de icono" o indicadores (comúnmente llamados EraIcons) en algún lugar de la página (incluyendo el encabezado). Ambos son difíciles de ver y usar en dispositivos móviles, y la recomendación de moverlos a la navegación de la infobox aplica para ambos ejemplos.

Ningún elemento de bloque (es decir, que no sea texto) es tan importante como la infobox en un artículo. En cierto sentido, junto con la sección de introducción, las infoboxes proveen de contexto y puntos de datos sobre el asunto de un artículo. Como tal, reciben un trato especial en la piel móvil y tienen mejores indicadores para Google. Su importante posición las vuelve ideales para navegación y conectividad a través de enlaces hacia páginas muy relacionadas.

Un problema con las secciones y páginas que contienen imágenes, tablas y galerías es que muchas veces no hay un "ancla" narrativa para explicar el contexto. Esto es con un fin tanto semántico (para que Google entienda la relación entre el modelo que crea para una página y la tabla o imagen mencionada) como de accesibilidad (que los lectores de pantalla y otros dispositivos de ayuda puedan recibir una pista de si la información es relevante o no antes de interpretar la tabla o imagen). Idealmente, todas las imágenes deberían de tener un pie de imagen (texto que pone la imagen en perspectiva para el artículo) y/o texto alternativo (el cual describe literalmente la imagen para aquellos que no pueden verla). Dicho de otro modo, el texto alternativo explica qué es algo, y el pie de página explica porqué está ahí. Para galerías grandes que pueden agruparse de manera lógica, es mejor dividirlas en galerías más pequeñas. Intercalarlas con el texto narrativo para que se complementen mutuamente sería lo ideal; tales estructuras funcionan bien en todos los dispositivos.

Acortando páginas

No hay nada de malo con las páginas largas (desde la perspectiva de un motor de búsqueda). Como se mencionó antes, tienen mejor probabilidad de ser interpretadas como modelos de contenido completos por el Passage Ranking de Google ya que se analiza la página completa. Si el contenido está bien organizado, la atención del lector debería de tener mucho para informarse y entretenerse sin que haya puntos en específico que sean difíciles de encontrar.

Sin embargo, también hay que mencionar que colocar bloques de contenido en pestañas interactivas (también conocidas como tabbers) presenta obstáculos técnicos. Editar bloques de wikitexto que están dentro de código complejo (párrafos dentro de una función parser) es más difícil con la interfaz del Editor Visual usada por la mayoría de editores, y también hace más difícil identificar dónde comienza y termina un elemento. La capa de JavaScript interactivo aumenta la puntuación del signo vital FID por la manera en que se muestran los elementos: si el tabber está en un área inicialmente visible de la página cuando esta carga, también aumentará el puntaje de CLS debido al desplazamiento que provoca. Las acciones de las pestañas en sí mismas que revelan contenido pueden no funcionar correctamente en dispositivos móviles. Además, algunos reportes indican que el contenido oculto en las otras pestañas puede no ser percibido por Google como importante.

Además, quizás incluso más importante, hay que tener en cuenta la experiencia del usuario: el contenido detrás de pestañas secundarias está "fuera de la vista, fuera de la mente" y es menos probable que los lectores lo vean. Las pestañas después de la primera son vistas con menor frecuencia, con cada par siendo menos común de ser activado que el anterior. La mayor parte del tiempo, los lectores ni siquiera saben que hay información que no está directamente visible para ellos, y pasarán por alto lo que buscan porque está fuera de la vista.

Por estos motivos, usar tabbers para "acortar" páginas está lejos de ser ideal para el rendimiento y la experiencia en la mayoría de casos. Si se usan tabbers, la guía de usabilidad de los expertos de experiencia de usuario sugieren que:

• No deben de anidarse entre sí.
• El nombre de las pestañas debe de ocupar solo una fila.
• El nombre de las pestañas debe de ser descriptivo.

La inclusión de DataTablas en el diagrama destaca una característica a enfatizar. Disponibles próximamente como parte de los scripts de Dev Wiki, las DataTables añaden muchas funcionalidades que mejoran la experiencia con largas tablas de datos. Cabe mencionar que usar múltiples infoboxes en una misma página tampoco se recomienda (por el tiempo de procesamiento y por el bien del procesador del motor de búsqueda), y suele ser mejor consolidar múltiples infoboxes (en especial aquellas que tienen muchas características en común) en una sola infobox usando la función de <panel>.

Portadas y navegación

Las portadas son especiales en los wikis por varios motivos. Para las máquinas y humanos, ingresar a la URL principal del wiki (a diferencia de la URL de una página en específico) representa el punto de entrada principal desde el cual comienzan a conectarse las páginas a través de enlaces. Google interpreta los enlaces de la portada (y la barra de navegación local) como lugares importantes para entender el tema de un wiki. Conforme Google examina el wiki por primera vez, sin conocer nada sobre el tema, asume que todos los enlaces tienen la misma importancia. Esto es fácil si hay 10 o 20 enlaces a páginas y categorías. Cuando componentes o paneles añaden cientos de enlaces a la portada, el peso relativo de estos enlaces se acerca a cero. Como hemos mencionado en esta página varias veces, esta también es la manera en que los humanos piensan: tener demasiadas opciones lleva a una "parálisis de decisión"; el efecto es que no saben dónde comenzar a revisar para entender correctamente.

Por lo tanto, por motivos técnicos y de experiencia de usuario, se recomienda reducir los enlaces de la página principal y dejar solo aqquellos que llevan a los artículos y categorías más importantes para entender el tema de un wiki. También se recomienda no usar componentes interactivos (widgets) que recuperen grandes listas de páginas, ya que afectan a la visualización, signos vitales y el rendimiento de indizado. Asumiendo que todas las páginas son enlazadas desde otras páginas, los rastreadores automáticos de contenido llegarán a ellas eventualmente. También ten en cuenta que, en la mayoría de casos, a Google se le menciona no seguir las páginas especiales o de discusión, e inicialmente recibirán un mensaje de error o serán redirigidos. No se recomienda enlazar a estas páginas desde la portada (y en muchos casos ya se encuentran en la navegación local o Especial:Comunidad, páginas que no son inmediatamente visibles para Google).

Existen muchas oportunidades para incluir un video en un wiki, pero se recomienda un máximo de dos a tres videos incrustados. Tanto el impacto en el rendimiento como el impacto visual de tener más videos en una página que se visita con frecuencia termina limitando la efectividad de cada video.

Tipografías e importaciones

Las tipografías especiales pueden ser increíbles (siempre y cuando tengamos en cuenta algunas reglas básicas sobre tipografía), pero también afectan al rendimiento del wiki. Las tipografías en los wikis vienen en dos variedades: importaciones o subidas en el wiki. La opción ideal para fines de rendimiento es usar una tipografía disponible en Google Fonts, y combinar su URL de importación cuando se usen varias. Para tipografías subidas en el wiki, procura utilizar solo WOFF2; este es un formato de archivos comprimido TrueType/OpenType optimizado para la web y soportado por la mayoría de navegadores populares, y hay varias herramientas de conversión en línea para obtener un archivo WOFF2 a partir de otros formatos. Usar un número limitado de tipografías (no más de 3) mantiene al wiki con una apariencia más limpia y profesional, y combinar sus URLs de importación (cuando se usa Google Fonts) es lo mejor para el rendimiento.

Fuera de Google Fonts (que tiene un sistema de distribución de contenido robusto y rápido), evita importar o enlazar a tipografías externas, JavaScript, CSS, imágenes o cualquier otro recurso fuera del sistema de Fandom. Existen muchos problemas de seguridad potenciales y hay un impacto considerable para el rendimiento al importar recursos de sitios externos, y suman tiempo al proceso de carga.

Complejidad de páginas y plantillas

Las páginas largas no siempre son páginas complejas, y viceversa. Las páginas que son procesadas a través de capas de plantillas dentro de plantillas tardan más tiempo en convertirse en HTML. Las páginas que son creadas casi completamente usando una sola plantilla (por ejemplo, plantillas de estructura de páginas) son especialmente difíciles de procesar y requieren de más recursos del servidor; en su lugar, todos los wikis pueden solicitar y probar la nueva extensión de Page Forms que permite estructurar páginas para una edición consistente. Estos formularios pueden ser más efectivos que las plantillas de precarga a la hora de crear páginas de un tipo en específico.

Al lidiar con plantillas especialmente complejas (aquellas con muchos #if, operaciones costosas o funciones parser), una conversión a Lua (un lenguaje disponible como alternativa que es más poderosa, eficiente y liviana) puede ser más conveniente, especialmente cuando tu plantilla se usa con frecuencia o se llama desde otras plantillas. Lua es una herraminta poderosa, y puedes encontrar ayuda si tienes problemas en nuestro servidor de Discord. Usar Lua es casi siempre más rápido que anidar plantillas.

Tener una infobox portátil en una página provee de información de manera efectiva a Google (llevando a un mejor posicionamiento). También es un elemento con un rendimiento excepcional, procesando sus datos de manera más eficiente. En comparación, usar tablas para infoboxes y otros elementos de diseño no funciona tan bien en dispositivos móviles o resoluciones diferentes. Anidar tablas dentro de otras también es un problema conocido para la portabilidad de una página (es decir, la manera en que se muestra el contenido a través de dispositivos y pieles), por lo que debería de evitarse.

Datos y transclusión

La manera ideal de mostrar los mismos datos en múltiples páginas es manteniendo todos los datos en la página en que quieres mostrarla (es decir, des-centralizándolos). Aunque esto requiere de más esfuerzo a la hora de actualizar, hace más rápido el procesamiento de la página. Utilizar automatización en exceso para aumentar el texto tiende a hacer el texto más difícil de entender para los nuevos editores y alarga el tiempo que demora procesar cada página.

Muchos wikis que necesitan fuertemente de datos usan opciones más ligeras, como Semantic MediaWiki o Cargo, para distriburi la información usando las páginas de artículos para almacenar los datos. También hay opciones de peso más moderado, como DPL o la Transclusión de Secciones Limitada, para tomar bloques de contenido de una página y colocarla en otra. Otros, cuando no pueden usar estas opciones, optan por almacenar los datos de manera centralizada en módulos de Lua y tratarlos como bases de datos. Almacenar datos en una ubicación central como un módulo de Lua o una plantilla es naturalmente más complicado para el rendimiento y afecta negativamente al tiempo de carga de las páginas.

Una web en evolución

Es importante mantener feliz a Google, porque es así como atraemos a visitantes. Pero Google está basado en el pensamiento y hábitos humanos, por lo que Google hace lo que haga felices a los humanos. Estas no son penalizaciones que Fandom impone en los wikis, sino medidas para mantener relevantes los wikis individuales en una web que sigue evolucionando.

Referencias