Ya os comenté hace unos días que esto daba para hacer una serie, bueno mejor en este caso una miniserie de dos capítulos 🙂 Así que vamos con WPO is the new SEO (T1 E2).
Previously in WPO is the new SEO…
Bueno, ahora en serio. En el anterior artículo definimos lo que era WPO y hablamos de la importancia que ha tomado últimamente, además de dar las primeras pinceladas de cuatro aspectos a tener en cuenta para optimizar el performance de nuestra Web, que recuerda que no es otra cosa que el Web Performance Optimization o, dicho en castellano antiguo, que la Web cargue rápido. Estos cuatro aspectos eran: Velocidad de carga; usabilidad; adaptación a móviles y optimización de los recursos.
Y para ello definimos una hoja de ruta con los siguientes paso: Auditoría; hosting e internet 2.0; cachés y CDNs, dejándonos para este artículo el resto de paradas en nuestra ruta, a saber: Contenidos, adaptación a entornos móviles; gestión de recursos; seguimiento y para completar esta ruta circular sin fin: de nuevo auditoría.
Contenidos
Ya lo sabéis, el contenido es el rey y en los días que nos ha tocado vivir, el contenido multimedia es quien manda.
Parece que si no publicamos en un artículo una imagen o un vídeo somos unos carcas y nadie nos leerá. Pero esto trae un problema del que a veces no nos damos cuenta: un archivo de imagen, y no digamos ya un archivo de vídeo, ocupa más que un archivo de texto, y claro, luego pueden venir los problemas a la hora de la carga de la página, lentitud en la carga de nuestro contenido…
¿Soluciones? seguro que, como para otros problemas, cada maestrillo tiene su librillo. Y este es el mío.
Imágenes
Con las imágenes suele haber, desde mi experiencia, dos errores de los que mi amigo Joan Boluda denomina “septembrinos”, es decir que te mandan directamente a la recuperación en el mes nono (aunque ahora vamos a tener que cambiarlo por “junianos” o algo así).
El primer error es subir una imagen en un tamaño y peso que NO es el que vamos a mostrar en nuestra Web y no optimizar y crear versiones a mostrar según el dispositivo y el segundo error es subir, cuando no es necesario, imágenes en formato sin comprimir, como por ejemplo en png.
En el primer caso, imaginemos que tenemos una fantástica foto de 2.000 píxeles que tenemos que subir a nuestra Web, cuyo ancho válido para navegador de ordenador no admite más de 800px. ¿Podemos hacer eso y que se muestre bien en los 800 píxeles? si, claro. Pero ¿Para qué vamos a subir un archivo que a lo mejor pesa 2MB y luego andar con código redimensionándola si podemos subir un archivo de 100 KB, o menos, que se ajusta al tamaño de nuestra Web?.
Hagamos esto antes, redimensionemos y subamos esta imagen con el tamaño, y peso, óptimo que vamos a servir.
Para poderlo hacer dos herramientas: PhotoShop, o cualquier programa de retoque de imágenes que uséis para redimensionar la imagen, aquí van cinco alternativas a PhotoShop que puedes usar desde tu navegador y tinypng una herramienta Web que os permite comprimir el tamaño de vuestras imágenes de forma online y gratuita. Y que el nombre no os engañe, comprime tanto pngs como jpgs.
Y para los más pro, la gente de tinypng tiene un plugin para PhotoShop, este si que tiene un costo de $50 , que nos permite desde la propia herramienta comprimir la imagen con la que estamos trabajando.
Y si usas WordPress, existen múltiples plugins que nos van a permitir de forma online comprimir nuestras imágenes de forma automática. Yo suelo usar, y en infinitopuntocero lo tenemos instalado, WP Smush, que permite tanto comprimir las imágenes que ya subiste como comprimir de forma automática las que vayas subiendo en el futuro. Dispone de versión gratuita, la que os he dejado en el enlace anterior y de versión de pago: WP Smush Pro.
Y en el caso de los archivos png, sólo una advertencia. Si no necesitamos que haya algo transparente en la imagen, no usemos png, ya que este formato de archivo no va comprimido. Es más, si necesitamos subir un logo y este tiene que ir con transparencia, intentemos usar mejor un archivo “svg” que al menos nos permite redimensionar con facilidad y sin perder nada de calidad y sin variar de tamaño del archivo.
Videos
Si una imagen tiene ya un tamaño respetable, si hablamos de un vídeo, el tamaño del archivo aumenta de forma exponencial, y si encima queremos cargarlo con cuanta más resolución sea posible, ya nos vamos a tamaños de archivo imposibles de mover.
En el caso de los videos mi consejo es, NO alojéis nunca, pero nunca, nunca, nunca, el video a vuestra Web.
Tenéis un par de fantásticas plataformas que se llaman Youtube y Vimeo que están para eso y que lo hacen fantásticamente.
Además del problema de carga de la Web podéis encontraros con que os fundís el ancho de banda que tenéis con vuestro proveedor de acceso. Aparte de destrozar toda la optimización que estuvierais haciendo de vuestra Web.
LazyLoad
Y un último consejo a la hora de cargar contenidos de una página en la que tengáis muchas imágenes: Usar lo que se llama lazyload que no es otra cosa que ir cargando el contenido de la página de forma diferida, en función de cuando el usuario lo va solicitando, por ejemplo, mientras va haciendo scroll. Podéis ver un ejemplo en Ivoox cuando cargas el contenido de un canal, que no te muestra a la primera todos los podcast del mismo, si no que va cargando de 20 en 20, de forma que cuando empiezas tienes cargados los últimos 20 y según llegas al final, carga los 20 siguientes.
En resumen, subir las imágenes en el tamaño, y peso, que vayáis a usar y en el caso de otros contenido multimedia, tira de Webs externas (Youtube o Vimeo para el caso de vídeo e Ivoox, Spreaker o libsyn si hablamos de podcast). Y siempre servir al usuario el recurso optimizado para cada dispositivo.
Adaptación al entorno móvil
Llegamos a uno de los puntos más importantes, la navegación desde dispositivos móviles.
Si no lo sabéis todavía, desde hace tres años se navega más desde el móvil que desde el ordenador. Y la forma de navegar desde el móvil difiere de la forma de navegar desde el ordenador, además de por el ancho de banda, por el tamaño de las pantallas y un factor quizás más importante: los dedos frente al ratón.
Esto nos debe hacer tener en cuenta dos factores:
- Que los contenidos para móvil deberían ser diferentes a los contenidos para Web, al menos en la forma de presentarlos.
- Que exista una versión “ligth” de estos contenidos para casos de ancho de banda bajo.
El responsive ni lo nombro, se da por supuesto como el valor a los legionarios, o a los toreros.
Mobile First
El planteamiento que nos deberíamos hacer es es siguiente: “Si más del 50% del tráfico de mi Web me llega desde dispositivos móviles, no debería pensar primero en diseñar mi Web adaptándola a este tráfico”.
Y eso significa, por ejemplo, que los botones de Call To Action (CTA) o llamada a la acción, tienen que tener el tamaño suficiente para que un Bigfoot pueda pulsarlo sin problemas, y no diseñar nuestra Web para hobbits. También significa que las imágenes que cargue en la página tienen que ir dimensionadas para el tamaño de las pantallas y que su peso no sea enorme, ya que en caso de baja conectividad, esto ralentizará la carga de mi Web….
AMP (Accelerated Mobile Pages)
En el caso de la versión “ligth”, tres letras AMP (Accelerated Mobile Page) que no deja de ser otra cosa que una nueva versión en HTML, de los de toda la vida de nuestra Web.
Ventajas: Que la carga, al eliminar muchos elementos superfluos que no son necesarios en móviles es muchísimo más rápida y que si configuramos esta versión de nuestra Web vamos a subir en el ranking de búsqueda de Google como la espuma. Si habéis implementado AMP queréis comprobar cómo está vuestra página, podéis a la página de prueba de AMP de Google Search Console.
Inconveniente: Que tendremos una version de la Web menos rica, más del estilo de los antiguos BBS (Bulletin Board System), que existían en la época que nos conectábamos a internet a través de modems a 9.600 bps.
Gestión de los recursos de la Web
Estamos acabando o casi acabando, que diría Rosendo, y nos queda optimizar los recursos que estamos empleando. Para ello cuatro reglas: Desactiva lo innecesario, optimiza, comprime y minimiza todo.
Y os estaréis preguntando, ¿Qué es lo que hay que desactivar, optimizar, comprimir y minimizar?. Bueno, yo os voy a hablar en este caso de lo que conozco, que es WordPress poniendo algunos ejemplos.
Desactiva
En WordPress hay muchas funciones que se cargan por defecto se usen o no, por ejemplo los iconos de la barra de administrador, el autoguardado de los artículos o páginas, las revisiones de los post que guarda, estilos de plugins que se cargan en cualquier página de la Web aunque no sean necesarios porque no se van a ejecutar ni mostrar, los pinbacks y trackbacks…. todo esto son funciones que, si no las tenemos que usar, no tiene sentido que se ejecuten, y con unas pocas líneas de código podremos ir arañando tiempo en la carga de nuestra Web.
Optimiza
A la hora de optimizar, por ejemplo, podemos eliminar las peticiones que hace WordPress a recursos que ya tenemos cacheados, conocidas como “query strings”, o por ejemplo, definir las urls absolutas que vamos a usar en nuestra instalación de WordPress y así evitar consultas a la BBDD o, siempre que sea posible y no nos rompa la Web, aplazar la carga de los JavaScript.
Comprime
Esto es válido tanto para WordPress como para cualquier Web. Mediante la compresión GZIP propia de los servidores Apache o Nginx, puedes comprimir mediante su activación en el archivo .httaccess o en el nginx.conf cualquier tipo de archivo, fuente, imagen… que se aloje en el servidor.
Minimiza
Y llegamos a la última pata de la gestión de recursos: la minimización. ¿En qué consiste? en quitar todo lo innecesario, por ejemplo, de los archivos HTML, CSS y JavaScript de tu web y, dentro de lo posible, dejar estos tipos de archivo en el mínimo número posible de ellos, unificando, por ejemplo, todos los CSS en un único archivo.
Para hacer esto en WordPress podéis utilizar un plugin que va bastante fino: Wp-Optimize, yo suelo emplearlo en las Web que administro y, salvo una vez con un problema al minimizar el JavaScript en una Web que tenia instalado el Revolution Slider, siempre me ha perfecto, aparte que es muy sencillo de configurar.
Seguimiento
Y ya si que estamos en el final del roadmap.
Nos queda el ir haciendo seguimiento de los cambios, para lo cual cada vez que hagamos una optimización, toca seguimiento de resultados, es decir medición.
Medición para la que deberemos tomar los resultados de la segunda pasada de las herramientas que usemos, para asegurarnos que el resultado es el real. Además hacerlo con el navegador en modo incógnito o habiendo borrado previamente todas las caches de nuestro navegador para evitar que estas nos den un falso resultado y desde varias redes distintas. Por último, acordarnos siempre de medir los resultados desde dispositivos móviles.
Auditoría
Y una vez acabado todo, estaremos en el inicio. Y más teniendo en cuenta que una Web no es algo estático, bueno si tu Web está hecha en HTML como a principios de siglo puede que sí, pero no creo que sea el caso.
Así que, cada vez que hagamos una actualización o cambio deberemos de auditar la Web para ver si ha habido cambios en el rendimiento de la misma. También es recomendable hacer una auditoría de forma regular, cada semana, cada quince días, cada mes… para poder ver que ha podido cambiar en los parámetros de rendimiento y, en función de esos cambios de rendimiento, ver que medidas de mejora deberíamos adoptar.
