En la tercera parte de esta serie describí cómo exprimir más el rendimiento de tu sitio optimizando los archivos multimedia estáticos. Este mes, un mes más tarde de lo previsto debido a una pequeña emergencia familiar, hablaré de los toques finales que hacen que tu sitio sea más refinado y profesional. En su mayoría tienen que ver con la forma en que tu sitio interactúa con los motores de búsqueda y las redes sociales, pero también hay un poco de rendimiento que se puede aprovechar ahí.
Calistenia en la construcción del sitio
Si has implementado todas las recomendaciones hasta ahora, estás en un 90% del camino hacia un sitio que funciona bien, se posiciona bien y es fácil de mantener.
No vamos a hablar de técnicas que son obsoletas (como combinar y minificar CSS y JavaScript - ¡en serio, no lo hagas!) o engorrosas para la mayoría de la gente (como intentar eliminar los espacios en blanco y las nuevas líneas de tu salida HTML o crear una Aplicación Web Progresiva). Las primeras no tienen sentido, las segundas tienen un público objetivo diferente al de las personas que siguen esta serie.
En su lugar, vamos a hablar de algunas cosas que puedes hacer para mejorar el rendimiento de tu sitio y pulir algunos puntos de fricción con tus usuarios. Por lo general, no es tan fácil como "instalar esto, hacer clic en eso, pim, pam", pero vale la pena el poco esfuerzo adicional. Si lo haces unas cuantas veces, se convertirá en algo natural y tus clientes quedarán impresionados por el rendimiento de los sitios que entregas.
OpenGraph y Twitter Cards
Si alguna vez has escrito una URL en una red social como Facebook (y sus otras propiedades web como Instagram, Messenger y WhatsApp), Twitter o LInkedIn o incluso en una aplicación de mensajería como Apple Messages, Slack, etc., habrás visto que ocurre algo interesante. Recibes una especie de tarjeta con una imagen y una breve descripción del contenido de la página. Incluso puedes obtener enlaces al autor o editor del contenido en esa red social. ¿Cómo funciona esa magia? La respuesta, amigo mío, no se la lleva el viento, son las metaetiquetas en el código fuente HTML de la página. En concreto, las metaetiquetas OpenGraph y Twitter Card.
Hay dos maneras de hacerlo: usar una extensión de terceros; o editar tu plantilla y hacer modificaciones en la misma.
La primera forma es posiblemente mucho más simple. Hay varias extensiones para Joomla que te ayudarán con eso. Una sencilla pero potente es Social Magick, que genera imágenes de tarjetas de título utilizando una combinación de una imagen de fondo / superposición / máscara, la imagen de contenido completo del artículo y el título - o una combinación de los mismos. Aviso: Este plugin es propiedad de la empresa de mi mujer y yo soy su principal desarrollador. Otro plugin que he utilizado es Phoca Open Graph, que te permite configurar tus etiquetas OpenGraph y Twitter Card para tu contenido. Este plugin utilizará la imagen del contenido completo de tu artículo como imagen de la tarjeta. Ambos plugins rellenarán los demás metadatos de OpenGraph a partir de la información de tu artículo.
Si estás desarrollando tu propia plantilla o sólo tus propias modificaciones de la plantilla, puedes utilizar código personalizado. Esto te da un control absoluto pero es, por supuesto, mucho más complicado.
El primer cambio es, obviamente, cambiar el elemento HTML raíz de tu plantilla para incluir el espacio de nombres de OpenGraph, por ejemplo:
<html lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>" prefix="og: http://ogp.me/ns#">
El lector astuto puede notar que estamos usando un prefijo en lugar de un espacio de nombres XML. Esta es la forma recomendada que funciona en los navegadores más nuevos, es decir, Internet Explorer 10 y posteriores.
A continuación, necesitas crear modificaciones de plantilla para la visualización de tus categorías y artículos que incluyan las etiquetas OpenGraph y Twitter Card necesarias. Por ejemplo, una modificación de plantilla de artículo (templates/MY_TEMPLATE/html/com_content/article/default.php) podría ser algo como esto:
$imagesRegistry = new \Joomla\Registry\Registry($this->item->images ?? '{}');
$imageIntro = $imagesRegistry->get('image_intro', null);
$imageFull = \Joomla\CMS\HTML\HTMLHelper::cleanImageURL($imagesRegistry->get('image_fulltext', $imageIntro))->url;
$canonicalURL = Route::_(ContentHelperRoute::getArticleRoute($this->item->id), true, Route::TLS_IGNORE, true);
$doc = $this->document;
$doc->setMetaData('og:type', 'blog');
$doc->setMetaData('og:title', $this->item->title);
$doc->setMetaData('og:description', $doc->getDescription());
$doc->setMetaData('og:site_name', $app->get('sitename'));
$doc->setMetaData('og:url', $canonicalURL);
$doc->setMetaData('og:image', $imageFull);
$doc->setMetaData('twitter:card', 'summary_large_image');
$doc->setMetaData('twitter:site', '@your_twitter_handle');
$doc->setMetaData('twitter:creator', '@your_twitter_handle');
$doc->setMetaData('twitter:description', $doc->getDescription());
$doc->setMetaData('twitter:title', $this->item->title);
Una modificación de la plantilla de categoría del blog también necesitaría un código similar al siguiente:
$canonicalURL = Route::_(ContentHelperRoute::getCategoryRoute($category->id), true, Route::TLS_IGNORE, true);
$doc->setMetaData('og:type', 'blog');
$doc->setMetaData('og:title', $this->params->get('page_title', $category->title));
$doc->setMetaData('og:description', $doc->getDescription());
$doc->setMetaData('og:site_name', $app->get('sitename'));
$doc->setMetaData('og:url', $canonicalURL);
$doc->setMetaData('og:image', \Joomla\CMS\HTML\HTMLHelper::cleanImageURL($category->params->get('image'))->url);
$doc->setMetaData('twitter:card', 'summary_large_image');
$doc->setMetaData('twitter:site', '@your_twitter_handle');
$doc->setMetaData('twitter:creator', '@your_twitter_handle');
El uso de modificaciones de plantilla obviamente funciona mejor si ya tienes la intención de hacer tu propia plantilla, por lo tanto, vas a crear una gran cantidad de modificaciones de plantilla de todos modos. Si no estás seguro, opta por el método de los plugins de terceros.
Carga previa de DNS y de recursos externos
En algún momento anterior de la serie dije que los navegadores no saben por arte de magia qué archivos necesitan solicitar cuando están cargando la página, sino que empiezan a cargar los archivos a medida que se dan cuenta de que los necesitan o de que los has empujado al navegador con HTTP/2 Push. He mentido un poco. Puedes dar algunas pistas al navegador para que empiece a preparar las cosas mientras todavía está descargando los primeros bytes de tu contenido HTML usando las etiquetas de enlace DNS prefetch y preload. Pero creo que me estoy adelantando.
Carga previa de DNS
Cuando describí cómo un navegador recupera los archivos CSS, JavaScript y de imagen necesarios para representar la página, utilicé un modelo simplista en el que el navegador envía una petición a "tu servidor". La suposición tácita era que "tu servidor" se refiere al mismo servidor y nombre de dominio como el que está cargando el contenido HTML. En la mayoría de los sitios Joomla este es el caso. Sin embargo, tu sitio puede estar utilizando un CDN externo para alojar algunos archivos multimedia, incluir CSS de Google Fonts o un recurso similar, cargar JavaScript desde un servicio externo y así sucesivamente. Todos estos son recursos alojados en un nombre de dominio diferente al que aloja tu sitio y entrega su contenido HTML. Tu navegador no puede conectarse mágicamente a estos nombres de dominio externos; los nombres de dominio deben resolverse primero en una dirección IP mediante una consulta DNS.
Las consultas DNS pueden ser lentas, especialmente en conexiones de alta latencia como las de satélite, celular o simplemente WiFi compartido de mala calidad - cuando la pandemia termine y podamos volver a trabajar desde cafés, hoteles y conexiones WiFi de aeropuertos. Esto añade un retraso a la carga de ese recurso que puede variar desde lo molesto (grandes desplazamientos de la disposición) hasta lo francamente problemático (una inclusión de JavaScript no diferida y no asíncrona está haciendo que la página se detenga al cargar).
Utilizando la carga previa de DNS se puede avisar al navegador, diciéndole esencialmente que tendrá que resolver estos nombres de dominio en el curso de la representación de la página. El navegador puede hacer las consultas de DNS mientras está esperando a que se cargue un archivo JavaScript o CSS que se está bloqueando, ahorrando al usuario algo de tiempo en las partes posteriores de la renderización de la página.
Otra buena razón para proporcionar la pista de carga previa de DNS es cuando se sabe que una interacción del usuario provocará la carga de un recurso desde un sitio externo. Por ejemplo, si sabes que al hacer clic en un botón "Me gusta" se producirá una conexión con el nombre de dominio de una red social, tiene sentido decirle al navegador que resuelva el nombre de dominio antes de tiempo para que ese botón parezca más receptivo a la interacción del usuario.
La mejor manera de hacerlo es en el index.php de tu plantilla o en tus modificaciones de plantilla.
Por ejemplo, digamos que tu sitio va a cargar una imagen de cdn.example.com cada vez que el usuario haga clic en un botón de la página. Hacer que el navegador resuelva los DNS antes de la interacción con el usuario ahorrará un tiempo valioso.
Si estás haciendo esto en el index.php de tu plantilla necesitas esto:
$this->getPreloadManager()->dnsPrefetch('https://cdn.example.com');
No olvides que este código debe usarse al principio del archivo index.php de tu plantilla, antes de que extraigas o generes la cabecera del documento. El objeto gestor de carga previa del documento sólo aplica los cambios a la cabecera del documento.
Desde el interior de una modificación de plantilla, en su lugar tienes que hacer:
$this->getDocument()->getPreloadManager()->dnsPrefetch('https://cdn.example.com');
Conexión previa
Que el navegador haga la consulta DNS por adelantado es estupendo. Sin embargo, si sabes que el navegador necesitará definitivamente conectarse al sitio externo para extraer los recursos utilizados para renderizar la página -como CSS, JavaScript, imágenes o archivos de fuentes-, tiene aún más sentido decirle al navegador que abra una conexión HTTP con el servidor externo y que la mantenga preparada. Esto va más allá de la carga previa de DNS. Hace la resolución DNS, el intercambio TCP (abre la conexión con el servidor) y la negociación TLS (se prepara para usar HTTPS). Deja una conexión con ese servidor abierta y lista para ser utilizada.
Esto funciona de la misma manera que la carga previa de DNS, pero en su lugar utilizará el método preconnect() del gestor de carga previa.
Digamos que quieres usar Google Fonts. Esto significa que está cargando el CSS desde fonts.googleapis.com que, a su vez, carga los archivos de fuentes desde fonts.gstatic.com. Por lo tanto, en la página index.php de tu plantilla tienes que hacer:
$this->getPreloadManager()->preconnect('https://fonts.googleapis.com', []);
$this->getPreloadManager()->preconnect('https://fonts.gstatic.com', []);
Igualmente con la preconexión, si estás haciendo esto desde dentro de una modificación de plantilla necesitas reemplazar $this por $this->getDocument() ya que el contexto de ejecución es diferente.
Carga previa de recursos
En algunos casos, los archivos que necesitan ser cargados no son inmediatamente obvios para el navegador con sólo analizar el HTML de su página. Algunos recursos pueden ser referenciados desde un archivo CSS o JavaScript. Cuando esto ocurre, el navegador dice: "Oh, genial, déjame añadir otro archivo a mi lista de descargas". Esto puede tener un efecto adverso en el rendimiento de tu sitio porque ese archivo puede ser importante, por ejemplo, un archivo de fuente o imagen que causará un cambio de diseño, o un archivo JSON o JavaScript alojado externamente que sólo se hará evidente que es necesario cuando el navegador termine de analizar y ejecutar otra pieza de JavaScript. Esto último es muy común cuando se incluye código JavaScript de servicios de terceros.
De nuevo, puedes avisar al navegador diciéndole que necesitará recuperar un determinado archivo. Si se le da la pista muy pronto en la sección HEAD del documento HTML, el navegador puede optimizar la recuperación de ese archivo, es decir, empezar a descargarlo en segundo plano mientras su hilo principal está ocupado esperando y analizando cualquier CSS y JavaScript que se bloquee en la página.
Al igual que la carga previa de DNS, la carga previa de recursos funciona utilizando el objeto gestor de carga previa de Joomla.
Por ejemplo, si quiero cargar previamente un archivo de fuentes desde la página index.php de la plantilla:
$this->preloadManager->preload('https://cdn.example.com/my_font.woff2', ['as' => 'font', 'crossorigin' => 'anonymous']);
Es importante tener en cuenta algunas cosas.
- A diferencia de la carga previa de DNS, estás dando una URL completa a un archivo.
- El atributo
ases obligatorio e indica al navegador la intención de uso de ese archivo, por ejemplo, fuente, imagen, vídeo, etc. - El atributo crossorigin es esencialmente obligatorio para los navegadores modernos y les indica cómo manejar la autenticidad de las solicitudes. Si se establece como anónimo, no se envían cookies, autenticación HTTP o certificados SSL del lado del cliente, y siempre está permitido. Si se establece como use-credentials, se pasarán las cookies, la autenticación HTTP o los certificados SSL del lado del cliente, pero estará sujeta a la política de recursos de origen cruzado del sitio, que puede impedir que la solicitud se realice, anulando su esfuerzo por dar una pista al navegador.
- Cualquier recurso cargado previamente debe ser utilizado en un "corto periodo de tiempo" que en la mayoría de los navegadores es de entre 5 y 10 segundos. Si el recurso no se utiliza dentro de ese tiempo, es desalojado de la memoria caché, lo que significa que el navegador no lo utilizará, y el navegador imprime un mensaje airado en la consola - ¡y tú eres penalizado en las métricas de rendimiento de tu página!
Intercambio de fuentes
Esta es una característica importante cuando se utilizan fuentes personalizadas. Por defecto, el navegador tratará de adivinar si debe mostrar algún texto mientras tu fuente personalizada no haya sido cargada y analizada. Si tu tipografía CSS no incluye una fuente de respaldo del sistema, el comportamiento por defecto es "block" (bloquear), lo que significa que tu navegador no mostrará ningún texto antes de que recupere la fuente personalizada que hayas especificado.
¿Alguna vez has visitado un sitio que mostraba una porquería de texto para siempre y te sentiste frustrado mirando una página mayormente blanca con unos pocos elementos de imagen aquí y allá hasta que ¡puf! todo el texto aparecía de repente? Sí, es por eso.
Por suerte, puedes decirle al navegador que haga algo diferente utilizando el atributo CSS font-display. Ponerlo en swap significa que el navegador se impacientará y volverá a la fuente por defecto mientras espera que se descargue la fuente personalizada. Cuando la fuente personalizada se descargue, aunque sea después de varios minutos, volverá a renderizar la página con la nueva fuente. Si lo configuras como "fallback", el navegador también se impacientará, pero si la fuente personalizada no se carga en cuestión de segundos, se quedará con la fuente de respaldo del sistema e ignorará la fuente personalizada por completo.
Si estás utilizando Google Fonts, basta con sustituir /css? por /css2? en la URL y añadir &display=swap. Por ejemplo, cargar Noto Sans se convierte en:
< link href="https://fonts.googleapis.com/css2?family=Open+Sans&display=swap" rel="stylesheet">
Lo mejor es establecer buenas fuentes de respaldo y configurar la propiedad font-display como swap. Para las fuentes de los iconos deberías usar block para que lo que se muestre sea un espacio en blanco mientras se carga la fuente del icono.
Hablando de fuentes de respaldo, deberías incluir las fuentes del sistema por defecto como tus fuentes de respaldo. Por ejemplo, las fuentes sans serif pueden tener un respaldo de
BlinkMacSystemFont, -apple-system, "Segoe UI", "Roboto", Helvetica, Arial, sans-serif
que cubre los dispositivos Apple más recientes y los más antiguos, Windows 7 a 11, Android y los sistemas heredados, prefiriendo la fuente sans serif de la interfaz de usuario por defecto en cada plataforma. La idea es que el usuario vea un tipo de letra familiar en lugar de la típica y más fea sans-serif por defecto. En los dispositivos de Apple, por ejemplo, la fuente predeterminada del sistema es la San Francisco, en lugar de la Helvética.
Iconos del sitio (favicons)
En los viejos tiempos, cuando los dinosaurios vagaban por la Tierra y 800x600 píxeles se consideraba "alta resolución" -eso sería alrededor de 2001-, había favicons de 16x16 píxeles y 256 colores, originalmente destinados a presentar el logotipo de un sitio en los marcadores sitios favoritos del usuario. Avanzamos dos décadas y estos iconos ya no son de 16 píxeles cuadrados, 256 colores o están limitados a los marcadores.
Por supuesto, los iconos de favoritos siguen utilizándose en los marcadores y en las pestañas de los sitios, como hace 20 años. También se utilizan para mostrar iconos en los lanzadores de aplicaciones / pantallas de inicio de los teléfonos inteligentes y las tabletas cuando se crea un acceso directo para el sitio. Además, son utilizados por servicios de terceros para obtener un logotipo para tu sitio. Si no conocías este uso echa un vistazo a este CodePen de terceros.
Para complicar más las cosas, hay varios tamaños necesarios para las diferentes generaciones de teléfonos inteligentes, tabletas, navegadores y sistemas operativos. Puedes encontrar una gran referencia para todos ellos en https://github.com/audreyfeldroy/favicon-cheat-sheet
Si tuviéramos que hacer una lista corta que soportara todos los dispositivos, navegadores y sistemas operativos desde 2013 hasta 2022 inclusive, obtendríamos lo siguiente:
- Un archivo ICO de 16x16, 24x24, 32x32, 48x48 y 64x64 píxeles.
- Siete archivos PNG con los tamaños 32x32, 128x128, 152x152, 167x167, 180x180, 192x192 y 196x196 píxeles.
- Un PNG de 144x144 píxeles y un color de fondo para los mosaicos del sitio de Windows Modern UI, que están obsoletos pero no se han eliminado todavía (y se utilizan mucho en Windows 7, que la gente sigue utilizando por algún motivo).
Añadirlos a Joomla requiere editar el archivo index.php de la plantilla y poner esto antes de la salida del HEAD del documento HTML. Asumiendo que tus archivos están almacenados en images/logos/favicon tenemos el siguiente código:
$doc = \Joomla\CMS\Factory::getApplication()->getDocument();
$baseUrl = \Joomla\CMS\Uri\Uri::base();
// Good old 16px square favicon
$doc->addFavicon($baseUrl . 'images/logos/favicon/favicon-16.ico');
// Default fallback: 152x152 pixels
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-152.png', 'apple-touch-icon-precomposed', 'rel');
// Windows Modern UI tile
$doc->setMetaData('msapplication-TileColor', '#d43431');
$doc->setMetaData('msapplication-TileImage', $baseUrl . 'images/logos/favicon/favicon-144.png');
// All other sizes
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-196.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "196x196"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-192.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "192x192"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-180.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "180x180"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-167.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "167x167"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-152.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "152x152"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-128.png', 'apple-touch-icon-precomposed', 'rel', ['sizes' => "128x128"]);
$doc->addHeadLink($baseUrl . 'images/logos/favicon/favicon-32.png', 'icon', 'rel', ['sizes' => "32x32"]);
El problema obvio es que tienes que acordarte de hacer todos estos cambios, lo que puede ser poco práctico. Puedes automatizar esto subiendo sólo dos archivos en tu carpeta images/logos/favicon:
- favicon.ico, que todavía tienes que generar tú mismo, pero que puedes resolver incluyendo sólo el icono heredado de 16x16px
- favicon.png un PNG transparente de 512x512 píxeles con la versión de alta calidad de tu logo
A continuación, puedes utilizar este código sustancialmente más complicado para generar automáticamente todos los tamaños necesarios:
$doc = \Joomla\CMS\Factory::getApplication()->getDocument();
/**
* Generate favicons.
*
* You need to upload two files to the $basePath folder, by default images/logos/favicon :
* - favicon.ico which includes 16x16, 24x24, 32x32, 48x48 and 64x64 pixel images.
* - favicon.png a 512x512 pixel transparent PNG
*
* @param string $basePath Path with your favicons relative to your site's root
* @param int[] $favIconSizes List of sizes to generate e.g. [32, 57, 152], see https://github.com/audreyr/favicon-cheat-sheet
* @param string|null $tileColor HTML hex color for the IE Modern UI tile icon, null to skip generating it
* @param int $defaultSize Fallback favicon size when the browser doesn't request a specific dimension
*/
$faviconGenerator = function (string $basePath, array $favIconSizes, ?string $tileColor, int $defaultSize = 152) use ($doc) {
$ensureSize = function (int $size) use ($basePath) {
$filePath = JPATH_SITE . '/' . $basePath . '/favicon-' . $size . '.png';
if (!file_exists($filePath))
{
try
{
(new \Joomla\CMS\Image\Image(dirname($filePath) . '/favicon.jpg'))
->resize($size, $size)
->toFile($filePath, IMAGETYPE_PNG, ['quality' => 9]);
}
catch (\Exception $e)
{
}
}
return basename($filePath);
};
$baseUrl = \Joomla\CMS\Uri\Uri::base(false) . $basePath . '/';
// Fallback .ICO file
$doc->addFavicon($baseUrl . 'favicon.ico?' . $doc->getMediaVersion());
// Default favicon
$doc->addHeadLink($baseUrl . $ensureSize($defaultSize) . '?' . $doc->getMediaVersion(), 'apple-touch-icon-precomposed', 'rel');
// Internet Explorer Modern UI (formerly Metro) tile icon, classic Edge
if (!is_null($tileColor))
{
$doc->setMetaData('msapplication-TileColor', $tileColor);
$doc->setMetaData('msapplication-TileImage', $baseUrl . $ensureSize(144) . '?' . $doc->getMediaVersion());
}
// All other favicons
foreach ($favIconSizes as $size)
{
$doc->addHeadLink($baseUrl . $ensureSize($size) . '?' . $doc->getMediaVersion(), 'apple-touch-icon-precomposed', 'rel', ['sizes' => "{$size}x{$size}"]);
}
};
$faviconGenerator('images/logos/favicon', [
// Favicons size reference: https://github.com/audreyr/favicon-cheat-sheet
32, // Default fallback for most desktop browsers.
// 57, // Deprecated: Standard iOS home screen (iPod Touch, iPhone first generation to 3G), old Android
// 72, // Deprecated: First- and second-generation iPad
// 76, // Deprecated: iPad home screen icon
// 96, // Deprecated: GoogleTV icon
// 114, // Deprecated: iPhone retina touch icon with iOS <= 6
// 120, // Deprecated: iPhone retina touch icon with iOS >= 7
128, // Chrome Web Store icon & Small Windows 8 Star Screen Icon
// 144, // Deprecated: IE10 Metro tile for pinned site, iPad Retina with iOS <=> 6
152, // iPad Retina with iOS >= 7
167, // iPad Retina with iOS >= 10 (in practice iOS will still use 152×152)
180, // iPhone Retina
192, // Google Developer Web App Manifest Recommendation
// 195, // Deprecated: Opera Speed Dial icon (Not working in Opera 15 and later)
196, // Chrome for Android home screen icon
// 228, // Deprecated: Opera Coast icon
], '#d43431');Este código puede no dar los mejores resultados en todas las circunstancias. Los logotipos reducidos pueden aparecer un poco borrosos. Siempre que sea posible, genera tú mismo los PNG a partir de una fuente vectorial y ajusta manualmente el tamaño de los archivos PNG con ImageOptim o una herramienta similar.
Analíticas y avisos de cookies
Dado que navegas por la web como el resto de nosotros debes estar ya profundamente frustrado por los banners de cookies que pueblan cada rincón de la web. En la mayoría de los casos, las únicas cookies aplicables que no son obligatorias son las utilizadas por servicios de análisis como Google Analytics. Si tu sitio tiene que mostrar un banner de cookies sólo porque usas analytics párate a pensar: ¿realmente necesitas las funciones que ofrece Google Analytics o servicios similares?
En la mayoría de los casos no necesitas esas funciones avanzadas. Si todo lo que necesitas es una analítica básica sobre cuántas personas han visitado tu sitio, si han llegado desde una búsqueda orgánica o desde un enlace de referencia y de qué país proceden, no tienes más que buscar en el panel de control de tu alojamiento, que probablemente ya ofrece AWstats o una solución similar. Estos funcionan analizando los registros de acceso del servidor web y no requieren cookies, por lo tanto no hay banners de cookies en tu sitio.
Otra solución es utilizar un servicio de análisis propio como Matomo (antes llamado Piwik). Ofrece la mayoría de las características que obtendrías con Google Analytics, pero como es una solución de un proveedor que cumple con el GDPR y la CCPA, ni siquiera necesitas mostrar un banner de cookies. Incluso puede importar datos de Google Analytics para que tengas continuidad de tus datos si eso es importante para tu caso de uso comercial.
Al eliminar la necesidad de un banner de cookies, haces que tu sitio sea más fácil de navegar y mucho menos frustrante para tus usuarios. Saber que puedes hacerlo sin sacrificar los datos que necesitas para tomar decisiones de negocio y sin obligar a tus usuarios a compartir sus datos con un tercero que gana dinero con la venta de anuncios personalizados (Google es principalmente una red de anuncios, por si no te habías dado cuenta) es un gran estímulo.
Oh, sí, ¿no tener que usar banners de cookies? ¡Eso hace que el rendimiento de tu página sea mucho mejor!
Modo oscuro
Lo más probable es que el diseño de tu sitio sólo tenga una combinación de colores y lo más probable es que sea un tema "claro", es decir, un fondo brillante con texto oscuro. Este ha sido el caso de la mayoría de los sitios web en las últimas dos décadas y es coherente con lo que la mayoría de los sistemas operativos solían ofrecer sólo como opción.
Para algunos usuarios, esta combinación de colores es inaccesible y el uso de colores invertidos en la pantalla no es una buena solución: todos los colores se invierten, incluidas las ilustraciones y las imágenes, lo que provoca una experiencia desagradable. Ofrecer un esquema de color oscuro para tu sitio también lo hará más accesible. También hará que tu sitio sea más atractivo para las personas que simplemente prefieren los esquemas de colores oscuros sobre los claros - un buen punto a considerar si el público objetivo de tu sitio son los geeks y los jugadores.
Si tu plantilla utiliza Bootstrap 5 puedes añadir soporte automático para el modo oscuro con mi plugin DarkMagic.
En mi propio blog he escrito más sobre qué es el Modo Oscuro, por qué y cómo utilizarlo y he realizado una presentación sobre el tema del Modo Oscuro. Simplemente enlazaré a estos recursos en lugar de repetirme en lo que ya es un artículo realmente largo.
AMP
Cuando empecé a trabajar en esta serie de artículos tenía la intención de recomendar AMP (Accelerated Mobile Pages) para tu sitio. Ya no estoy tan seguro.
Si aún no lo sabes, AMP es un subconjunto de HTML con algunas peculiaridades que hacen que se cargue más rápido en los dispositivos móviles - o, al menos, que lo parezca. Es mucho más restrictivo que un sitio adaptativo normal. El atractivo del estándar AMP es que Google dará prioridad al contenido AMP en los carruseles de resultados de búsqueda cuando un usuario realice una búsqueda mediante la aplicación de Google en un smartphone.
El inconveniente es que AMP es muy específico de Google y no es compatible fuera del ecosistema de Google. Además, las personas que hagan clic en los resultados de búsqueda que apunten a las páginas AMP de tu sitio verán google.com en la barra de direcciones de su navegador en lugar de tu sitio. Creo que estas son desventajas importantes que te aíslan de tu audiencia.
El hecho de que un miembro del Comité Consultivo de AMP haya renunciado recientemente porque consideraba que Google había secuestrado prácticamente todo el proyecto AMP en su propio beneficio y que el Fiscal General de Texas haya presentado una demanda antimonopolio contra Google que pondría fin al trato preferente de AMP en el carrusel de búsqueda me hace preguntarme si tiene algún sentido introducir AMP en tu sitio. Según mi experiencia, la integración es muy sencilla si quieres crear tu propia plantilla personalizada para tus páginas AMP.
Por último, según los datos analíticos que he recogido en mi propio sitio, AMP no atrae tanto tráfico como se supone. La mayor parte de mi tráfico proviene de enlaces directos desde otros sitios, de búsquedas orgánicas que llevan a mi plantilla adaptativa habitual y de las redes sociales. AMP apenas era un parpadeo en el radar de las fuentes de tráfico.
Así que, en lugar de decirte cómo integrar AMP en tu sitio, te diré que probablemente no deberías hacerlo. Sin embargo, si estás empeñado en implementarlo hay soluciones para Joomla. Yo he utilizado wbAMP pero tengo que advertirte que crear una plantilla personalizada es bastante complicado. Entre el momento en que escribí el primer borrador de esta serie y el día de hoy terminé eliminando AMP de mi sitio.
Continuará
Queda una última parte de esta serie. Se trata de algunas cosas más genéricas, no específicas de Joomla, que puedes hacer para que tu sitio sea más atractivo para los humanos en lugar de sólo para los motores de búsqueda y que se mantenga rápido. Hasta entonces, ¡feliz construcción de tu sitio!
Este artículo es una traducción de Joomla Performance Tuning IV: Site building calisthenics.
