Este año he vuelto a tener el honor de estar entre los seleccionados para dar una charla en WordCamp Santander. El título de la misma, como reza el post, fue Auditoría WPO en directo.
Antes de empezar hice un pequeño disclaimer. Quizá pueda parecer un poco pretencioso el título de la charla. Una auditoría como tal no puede hacerse en unos minutos. Mi intención era simplemente analizar por encima 2 ó 3 webs de entre los asistentes, ver cómo realizar ese análisis, ver cómo medir, cómo interpretar los mensajes que aparecen y cómo solucionarlos en WordPress. Al final sólo me dio tiempo a analizar una web: convuls.io, y fue una pena no tener más tiempo porque me hubiera gustado contar alguna cosita más.
Al principio, hice una pequeña introducción sobre lo que es el WPO, los factores o pilares básicos a tener en cuenta, técnicas de medición, herramientas para medir, vimos qué bookmarlets pueden venirnos bien para nuestro navegador, etc… Puedes verla pinchando aquí.
Tras esta breve introducción llego el turno del directo. Sólo un valiente como voluntario, así que un agradecimiento enorme para Roberto Tuñón por prestarse a que viéramos como tiene su página web de convuls.io.
Como dije antes, una pena no haber tenido unos minutos más, la charla se me paso volando. Sólo pude «auditar» la home, pero si realizáis vosotros por vuestra cuenta una auditoría de vuestro sitio, es importante que analicéis más páginas, no solo la home: listado de noticias, detalle de noticias, páginas o templates donde tengáis un formulario, etc… No todos los templates son iguales ni cargan las mismas cosas, es importante analizar diferentes páginas de tu sitio web.
Utilicé 3 herramientas para la presentación, aunque hay muchas más. Como dije no hay una que sea mejor que otra. Lo ideal es que te quedes con algo de cada una de ellas. Éstas herramientas fueron Google PageSpeed Insights, GTmetrix y Pingdom Tools. En la primera los resultados fueron los siguientes:
Lo primero que comenté es que no hay que obsesionarse con el 100 / 100. No todos los proyectos son iguales, no todos tienen las mismas funcionalidades, ni el mismo diseño, ni las mismas características, etc… Yo me lo tomo como una guía de buenas prácticas, pero tampoco recomiendo obsesionarse con la puntuación, porque en muchas ocasiones llegar al 100 puede implicar modificar el diseño, eliminar alguna funcionalidad, o incluso aplicar alguna técnica que puede afear el comportamiento de la página y hacer que aparezcan efectos como el FOUT, que personalmente no lo veo como algo bonito.
Relativo a la página de convuls.io:
- Eliminar el JavaScript que bloquea la visualización y el CSS del contenido de la mitad superior de la página: Quizá lo que más asusta a la gente. Siempre recomiento pararse a pensar si para nuestro proyecto aplica el enviar todos los scripts al footer, o si podemos poner el atributo async o defer a los mismos. Si podemos aplicarlo, perfecto. Pero en algunas ocasiones estas técnicas nos pueden dar problemas o generar conflictos.
- Especificar caché de navegador: A través de un plugin de caché o reglas en el .htaccess, podemos establecer una caducidad para nuestros recursos estáticos, de tal forma que una persona que entre por segunda vez en nuestro sitio, todas las imágenes, css y js se las descargará de su navegador en lugar de nuestro servidor, y tendrá una experiencia de usuario más rápida.
- Minificar JavaScript: Lo ideal es que de base utilices Grunt o Gulp para automaticar una serie de tareas de compilado, minificación, concatenación y uglificación de archivos CSS y JS. Es simple, los archivos resultantes pesan menos, y algo que pesa menos, por ende tarda menos ser descargado.
- Habilitar compresión: Un poco en la línea de antes. Con un plugin de caché o reglas en .htaccess podemos habilitar gZIP y nuestros recursos viajan comprimidos desde nuestro servidor hasta el navegador del usuario. Reducimos el uso de ancho de banda y los recursos tardan menos en descargarse porque sencillamente pesan menos
- Reducir el tiempo de respuesta del servidor: Mucha gente confunde esto con tener un mejor hosting o invertir en más cores, más núcleos, más RAM o un servidor dedicado para ti solito. Siempre digo que un buen hosting es importante, con la última tecnología (discos duros SSD, PHP7, HTTP/2, etc…), pero también lo es todo lo que se ejecuta por detrás cada vez que un usuario visita nuestro sitio. Una web que tenga plugins y o temas que realicen muchas peticiones o muchas consultas a BBDD, tendrá un tiempo de procesado mayor, por lo tanto esta regla es dificil que puedas cumplirla
- Optimizar imágenes: Siempre digo que quizá sea de lo más importante en cuanto al rendimiento, ya que las imágenes representan un porcentaje alto del peso total de nuestra web. Y es quizá una de las cosas más fáciles de corregir. Sólo hay que tener la precaución de no subir imágenes más grandes del espacio que realmente van a ocupar en nuestra web, y disponer de un plugin que te optimice la calidad y el peso de las mismas
Hasta aquí dió la charla. A modo de resumen:
- Importante medir, medir mucho
- Recoger mucha información de varias fuentes
- Interpreta esa información
- Actúa
- Vuelve a medir y comprueba lo que has mejorado
PD: Una cosa que se me olvidó comentar en la charla. En PageSpeed al final del análisis hay un enlace que reza: Descarga los recursos de imagen, JavaScript y CSS optimizados para esta página, donde puedes descargar todos los recursos optimizados que Google ha detectado en tu sitio.
PD2: No quiero dejar pasar la ocasión para felicitar de nuevo a todo el equipo de organización y voluntarios que han hecho un eventazo tremendo una vez más. ¡Enhorabuena chic@s!
Puede que también te interese
