I told you a few days ago that this was enough to make a series, well better in this case a miniseries of two chapters 🙂 So let's go with 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.
Contents
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.
It seems that if we don't publish an image or a video in an article, we're just a bunch of wimps and no one will read us. But this brings a problem that sometimes we do not realize: an image file, let alone a video file, occupies more than a text file, and of course, then can come the problems when loading the page, slow loading our content ...
Solutions? I'm sure that, as for other problems, each master has his own book. And this is mine.
Images
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.
In the first case, let's imagine that we have a fantastic 2,000 pixels photo that we have to upload to our Web, whose width valid for computer browsers does not support more than 800px. Can we do that and show it well in the 800 pixels? Yes, of course. But why are we going to upload a file that weighs maybe 2MB and then mess with code resizing it if we can upload a file of 100 KB, or less, that fits the size of our Web.
Let's do this first, let's resize and upload this image to the optimal size, and weight, that we're going to serve.
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.
And in the case of png files, just a warning. If we don't need something transparent in the image, don't use png, because this file format is not compressed. Moreover, if we need to upload a logo and it has to be transparent, let's try to use a "svg" file, which at least allows us to resize it easily and without losing any quality and without changing the size of the file.
Videos
If an image already has a respectable size, if we talk about a video, the file size increases exponentially, and if we want to load it with as much resolution as possible, we are already going to file sizes impossible to move.
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.
Adaptation to the mobile environment
We come to one of the most important points, navigation from mobile devices.
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.
This should make us take into account two factors:
- 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.
Disadvantage: That we will have a less rich version of the Web, more in the style of the old BBS (Bulletin Board System), which existed in the days when we connected to the Internet through modems at 9,600 bps.
Management of Web resources
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.
Deactivate
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.
Optimize
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.
Compress
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.
Minimize
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.
Follow up
And now we are at the end of the roadmap.
We have to keep track of the changes, so every time we make an optimization, we have to track the results, i.e. measurement.
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.
Audit
And once everything is finished, we will be at the beginning. And more taking into account that a Web is not something static, well if your Web is made in HTML as at the beginning of the century maybe yes, but I don't think it's the case.
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.
I invite you to leave your impressions and/or doubts in the contact form and to suggest new topics that you would like me to cover in these tutorials. I will be happy to answer you by email and write in this blog.
