Tal día como hoy hace 5 años comencé con el blog, y lo celebro con un pequeño lavado de cara. Y en esta entrada quiero explicar lo que he hecho, a modo de consejos para cualquier proyecto web.
Empecé con el blog en mi tiempo libre, estando de vacaciones y arranqué con lo puesto, como suele decirse Quick and Dirty. Creé un tema básico y comencé a escribir. Con el paso del tiempo le di un poco más de cariño y lo mejoré un poco. Ahora que he tenido más tiempo libre por el confinamiento, he podido dedicarle más atención y hacer una refactorización completa.
Visualmente no notarás muchos cambios. Ni soy diseñador ni puedo permitirme pagar a uno ya que el blog en sí no lo estoy monetizando (sigo sin patrocinador 🙁 ), quizá en un futuro… Así que me he enfocado más en la parte técnica.
Bye bye Bootstrap, hello SASS, Flex, Grid…
Uno de mis objetivos era eliminar Bootstrap. Me vino muy bien en su día ya que partía de una base, y a partir de ahí añadía las modificaciones que quería/necesitaba.
De Bootstrap no estaba utilizando ni un 25%, así que estaba cargando CSS innecesario y añadiendo reglas, clases, selectores, etc que sumaban peso y complejidad al CCSOM. Pasé de esto:
A esto otro:
La mejora es significativa, aunque lo siento si alguien visita el blog con un navegador antiguo 🙂 . Como puede observarse se reducen considerablemente las reglas, selectores, clases, etc… sólo con el mero hecho de quitarme la dependencia de Bootstrap y tener únicamente lo que me hace falta.
Aunque no soy especialista maquetador, y llevaba mucho tiempo sin tocar esta parte, he tenido la oportunidad de trabajar con Flex y Grid, y aprender de ello. Soy consciente de que esta parte es muy mejorable, y con el tiempo iré puliendo cosillas.
Todo esto lo trabajo con Gulp, tengo un archivo SASS por cada parte del blog (main, header, footer, menu, ratings, posts, form…) que proceso y concateno después a una hoja de reset.css. Y después minifico todo.
Y es Mobile First. Toda la maquetación se inicia desde dispositivos móviles, y apenas tengo algunas reglas en las media queries para adaptarlo a tablet y desktop, cosa de la que (para no ser maquetador) me siento bastante orgulloso.
Bye bye jQuery, hello Vanilla
Otro de los retos que me planteé para este cambio, era eliminar toda dependencia de jQuery, y ¡lo conseguí!
La verdad sea dicha, tengo poca funcionalidad en JavaScript, apenas el GoToTop, las votaciones, el lazy load, el click del menú y alguna cosilla del formulario, pero todo ese código lo he reescrito en Vanilla JavaScript.
Esto me ha permitido ahorrarme una petición, y unos cuantos kBs de peso. Ahora mi scripts.min.js pesa apenas 1,7 kBs, lo que resulta 1,1 kBs en transferencia (gzip). Sólo jQuery pesa 96.7 kBs (34.3 kBs de transferencia), así que la ganancia y optimización en este punto ha sido mayúscula.
Bye bye Crayon, hello PrismJS
Crayon Syntax Highlighter es sin lugar a dudas uno de los mejores plugins de WordPress para formatear el código. Me ha venido muy bien durante estos años para darle estilo a los snippets de código que compartía en los artículos.
Pero es un plugin muy pesado, tanto en CSS como en JS, y además dependiente de jQuery. Así que me puse a buscar una alternativa y encontré PrismJS. Un gran descubrimiento. Esta librería es muy fácil de implementar en tu desarrollo, y cuenta con la ventaja de que puedes personalizarla, así que te descargas sólo el CSS y JS necesario.
Y eso hice, seleccioné las 4 cosas que necesitaba y ahora apenas tengo 2,8 kBs de CSS (1,4 kBs de transferencia) y 40,9 kBs de JS (16,8 kBs de transferencia). Además, lo cargo condicionalmente, sólo en las páginas de detalle de posts, que es donde puede haber código y ser necesario.
Bye bye Spaguetti Code, hello OOP, Clean Code and Best Practices
Lo reconozco, tenía el tema mangas por hombro como comenté anteriormente. Lo hice prácticamente en 4 ratos y le hacía falta meterle mano.
¿Sabéis eso que dicen de que a los programadores les da vergüenza ver el código que hicieron hace un año? Imaginad hace 5, lamentable. Lo bueno de poder refactorizar tu propio legacy code, es experimentar en primera persona la evolución que has tenido en este tiempo.
Así que ahora todo está hecho en PHP7, POO, Namespaces, strict_types, estructurado modularmente, y he seguido un mistolobo entre los Coding Standars de WordPress y los PSR de PHP. Todo el código está documentado y siguiendo principios SOLID.
Además tengo un cargador condicional para todos mis hooks, lo que hace que sólo se invoquen las clases allá donde se utilicen, optimizando el rendimiento global del sitio.
Bye bye Classic Editor, hello Blocks
Aunque ya los últimos posts los he escrito con el nuevo Editor de Bloques, la verdad es que estaba retrasando lo inevitable hasta que di el paso. He convertido todos mis posts del editor clásico a bloques, y aún ando acostumbrándome a ello.
También he aprovechado para migrar un par de funcionalidades que tenía integradas en el editor clásico (para resaltar textos) al nuevo editor de bloques.
Y lo mismo con un par de shortcodes, los he migrado a bloques y ahora es más fácil contribuir su información. Probablemente el próximo artículo vaya sobre esto.
Algunos datos
Uno de los intereses personales que tenía, era ver cuanto era capaz de mejorar en rendimiento. Había hecho ya mis pinitos y lo tenía bastante optimizado pero sabía que tenía cierto margen de mejora. Nada mejor que comparar el antes y el después para verlo:
GTmetrix antes
GTmetrix después
Como puede observarse, la mejora es patente. Pese a que para algún gurú el no llegar al 100/100 en GTmetrix sea síntoma de que no está optimizado del todo, imagino que los que entiendan un poco de esto no se quedarán ahí y verán otros indicadores, donde se puede comprobar el buen rendimiento del sitio.
No tengo el 100/100 porque me falta la CDN y el HTTP/2, simple y llanamente. Y estos dos «filtros» no los paso, porque como comenté anteriormente no estoy monetizando el blog y no quería incurrir en ese inversión gasto respecto a la CDN, y no tengo HTTP/2 porque está alojado momentáneamente en un hosting que no dispone de él.
Pingdom Tools antes
Pingdom Tools después
Aquí podemos ver un poco lo mismo que en GTmetrix, al reducir las peticiones y el tamaño de las mismas, esto se traduce en una mejora del tiempo de carga.
Es puro sentido común. Al reducir el peso en un 40% aprox, más rápido se transfiere y más rápido se muestra. Y como en alguna ocasión he dicho: la petición más rápida es aquella que no se hace, al eliminar alguna petición (como jQuery), es tiempo que ahorramos también.
Inspector de Chrome antes
Inspector de Chrome después
Las mediciones realizadas tanto en GTmetrix como Pingdom Tools, son configurando la ubicación en Londres. Por eso siempre me gusta también comprobar el rendimiento con mi navegador y desde mi casa. En mi caso con una buena conexión (300 MB de fibra):
Podemos observar de nuevo que antes era rápido pero ahora lo es aún más. Y eso que me falta la CDN, el HTTP/2 🙂 . Y ya si tuviera un buen servidor con caché tipo Varnish, sería apenas un parpadeo.
Ha sido un cambio total, es probable que alguna cosa no vaya fina del todo, así que seguiré poco a poco puliéndolo y optimizándolo más si cabe, que siempre hay micro optimizaciones que hacer.
Puede que también te interese
