Je vous ai dit il y a quelques jours que c'était suffisant pour faire une série, bien meilleure dans ce cas-ci une mini-série de deux chapitres 🙂 Donc allons y avec WPO c'est le nouveau SEO (T1 E2).
Auparavant dans WPO se trouve le nouveau 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.
Contenu
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.
Il semble que si nous ne publions pas une image ou une vidéo dans un article, nous ne sommes qu'une bande de poules mouillées et personne ne nous lira. Mais cela pose un problème dont nous ne nous rendons pas toujours compte : un fichier image, sans parler d'un fichier vidéo, occupe plus qu'un fichier texte, et bien sûr, peuvent alors venir les problèmes de chargement de la page, de chargement lent de notre contenu ...
Des solutions ? Je suis sûr que, comme pour d'autres problèmes, chaque maître a son propre livre. Et ceci est à moi.
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.
Dans le premier cas, imaginons que nous ayons une fantastique photo de 2 000 pixels que nous devons télécharger sur notre web, dont la largeur valable pour les navigateurs informatiques ne dépasse pas 800px. Pouvons-nous faire cela et bien l'afficher dans les 800 pixels ? Oui, bien sûr. Mais pourquoi allons-nous télécharger un fichier qui pèse peut-être 2MB et ensuite nous embrouiller avec un code de redimensionnement si nous pouvons télécharger un fichier de 100 KB, ou moins, qui correspond à la taille de notre Web.
Faisons cela d'abord, redimensionnons et téléchargeons cette image à la taille et au poids optimaux que nous allons 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.
Et dans le cas des fichiers png, juste un avertissement. Si nous n'avons pas besoin de quelque chose de transparent dans l'image, n'utilisez pas de png, car ce format de fichier n'est pas compressé. De plus, si nous devons télécharger un logo et qu'il doit être transparent, essayons d'utiliser un fichier "svg", qui nous permet au moins de le redimensionner facilement et sans perte de qualité et sans modifier la taille du fichier.
Vidéos
Si une image a déjà une taille respectable, si l'on parle d'une vidéo, la taille du fichier augmente de manière exponentielle, et si l'on veut la charger avec la plus grande résolution possible, on va déjà vers des tailles de fichiers impossibles à déplacer.
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 à l'environnement mobile
Nous arrivons à l'un des points les plus importants, la navigation à partir d'appareils mobiles.
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.
Cela devrait nous amener à prendre en compte deux facteurs :
- 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.
Désavantage : Que nous aurons une version moins riche du Web, plus dans le style de l'ancien BBS (Bulletin Board System), qui existait à l'époque où nous nous connections à Internet par des modems à 9 600 bps.
Gestion des ressources du 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.
Désactiver
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.
Optimiser
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.
Compresser
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.
Minimiser
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.
Suivi
Et maintenant, nous sommes à la fin de la feuille de route.
Nous devons suivre les changements, donc chaque fois que nous faisons une optimisation, nous devons suivre les résultats, c'est-à-dire les mesures.
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
Et une fois que tout sera terminé, nous serons au début. Et plus encore en tenant compte du fait qu'un Web n'est pas quelque chose de statique, eh bien si votre Web est fait en HTML comme au début du siècle peut-être oui, mais je ne pense pas que ce soit le cas.
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.
Je vous invite à laisser vos impressions et/ou vos doutes dans le formulaire de contact et à me suggérer de nouveaux sujets que vous souhaiteriez voir abordés dans ces tutoriels. Je serai heureux de vous répondre par courriel et d'écrire dans ce blog.
