Entramos en 2024, y el editor de bloques de WordPress, alias Gutenberg, lleva ya con nosotros nada menos que 5 años. La evolución ha sido espectacular en todos los aspectos, NADA hay que no se pueda hacer ya con él, más rápido y mejor que con cualquier otro constructor visual.
Imagen de master1305 en Freepik
Como suele ser normal y comprensible, muchas personas profesionales del desarrollo y diseño web, se resisten a cambiar de herramientas, cuando las que usan con regularidad y soltura les ofrecen buenos resultados. Quien escribe estas líneas, sin ir más lejos, siempre fue un gran enemigo de cualquier tipo de herramienta visual, hasta el punto de escribir los posts directamente en html, prescindiendo de WYSWYG. Por puro control. Y no hay poca gente como yo.
Automattic y la comunidad que desarrolla y mantiene WordPress, sabían del creciente problema de la invasión de «visual composers» y no han parado ni paran de trabajar para subsanar este error tan grave.
De hecho, para el perfil de los desarrolladores siempre se ha intentado vendernos el tema de la productividad, pero sabíamos que esta no era real si el simple hecho de cargar o hacer un guardado de una página o post en el administrador del sitio nos llevaba más de 5 minutos por la enorme cantidad de recursos que consumía el builder de turno.
Para el usuario «no coder», el que sólo quiere poner «un texto a la izquierda y una foto a la derecha en dos columnitas» los editores visuales como el archiconocido Elementor, son la máxima exponencia del término «false friend»: Facilidad de control visual de los bloques y elementos en las páginas, a expensas de sobrecargar el CMS hasta puntos de hacerlo reventar todo y lograr que el sitio web sea absolutamente inmanejable.
Automattic y la comunidad que desarrolla y mantiene WordPress, sabían de este creciente problema y no han parado ni paran de trabajar para evitar este error tan grave.
Y Google como siempre, también hace lo posible para que nos demos cuenta de lo que pasa: Por eso nos dan cada vez más herramientas y recursos, y maneras de entender qué es lo que pasa con los sitios web «overenginereed» (Core Web Vitals).
Por esto, antes de entrar a listar los motivos esenciales, te voy a explicar 2 muy importantes a nivel extra importante:
PRIMERO, LA MEMORIA Y RECURSOS EN TU BACKEND
A diferencia de los otros editores visuales, con todos sus paneles, sus cajitas, su navegador de bloques y jerarquía… que con frecuencia hacen que nuestro navegador web se cuelgue, el editor de bloques de WordPress está implementado usando React, una tecnología de front end basada en virtual dom y creada por Facebook, bueno, por Meta, para poder cargar muchos elementos (y microcambios) en la página sin digamos sacrificar la memoria en cada «repintado» de la página.
A grandes rasgos, es ligero de usar, no ralentiza ni tardarás los 5 minutos o más que puede llegar a tardar en guardarse un post usando Elementor o cualquiera de sus primos.
Además, pero no menos importante: El editor de bloques nativo de WordPress, guarda todo en el post, dejando intactas las tablas de infinitos post meta que usan los otros constructores. Base de datos siempre sana, limpita y FUERTE.
SEGUNDO: LA OPTIMIZACIÓN DE LOS RECURSOS EN TU FRONT END
Llevamos años cometiendo el error de hacer que por cada url de nuestros proyectos se tengan que cargar todo el css y js de absolutamente todo el site, el theme, el css extra cargado de !importants metido en calzador que viene luego, el css y js de los plugins, framework de responsive, framework de efectos y animaciones y por cada plugin extra de iconos de redes sociales, la colección completa de iconos para luego usar dos, etc.
Google nos lo alerta cada vez que usamos sus herramientas de medición de rendimiento: Optimice la carga de recursos de su sitio web. Demasiado.
Ya muchos desarrolladores separábamos los archivos por el tipo de vistas (css y js exclusivos de páginas, de posts, de woocommerce) pero siempre hemos seguido usando una carga común masiva de recursos.
No puede ser que, a dia de hoy, el css crítico para mostrar nuestra fotaza, y los cuatro párrafos que lleva un simple single post, implique cargar 1mb de css, por mucha minificación y compresión que apliquemos.
La tecnología del editor de bloques de WordPress, permite que nuestro theme detecte los recursos css y js requeridos por un bloque determinado, y estos sean integrados y requeridos desde la página o post sólo si el bloque está presente.
Esta práctica es un game-changer tan grande (y a nivel técnico, obvio) a nivel tecnológico diría yo que de tan obvia que es, se aplica poco más por un tema de mala implementación de las aplicaciones, que por conocimiento de su necesidad.
Pero vamos a lo esencial, como decíamos:
Los 10 motivos esenciales por los que debes pasarte al editor de bloques nativo de WordPress en 2024
- Porque es absolutamente gratuito. Ni freemium ni leches: El editor de bloques de WordPress es gratuito y de código abierto, lo que significa que no tienes que pagar por él y puedes personalizarlo según tus necesidades.
- Es -cada vez más- fácil de usar: El editor de bloques de WordPress es fácil de usar y no requiere conocimientos técnicos avanzados.
- Es super flexible y personalizable: El editor de bloques de WordPress es altamente personalizable y te permite crear diseños únicos para tus páginas y publicaciones. Con los patrones de bloques y los bloques adicionales creados por la comunidad no hay nada que no se pueda construir.
- Es compatible con la mayoría de los temas: El editor de bloques de WordPress es compatible con la mayoría de los temas de WordPress, lo que significa que no tienes que preocuparte por problemas de compatibilidad.
- Es súper seguro: El editor de bloques de WordPress es seguro y se actualiza regularmente para corregir cualquier vulnerabilidad de seguridad.
- Es el más rápido y eficiente: El editor de bloques de WordPress es rápido y está optimizado para una carga rápida de la página. Tanto en tu back end como en tu front end. Y NO ensucia tu base de datos, como hacen todos los demás.
- Es el más SEO-friendly: El editor de bloques de WordPress es SEO-friendly y te permite optimizar tus páginas y publicaciones para los motores de búsqueda.
- Es el más accesible: El editor de bloques de WordPress es accesible y cumple con los estándares de accesibilidad web.
- Es el más escalable y mantenible: Trabajar sobre un proyecto existente y de largo recorrido, elaborado con el editor de bloques nativo de WordPress ahorrará pesadillas de los desarrolladores y técnicos de mantenimiento web, que hereden dichos proyectos. Y esto se verá reflejado en horas de trabajo y en costes económicos.
- Optimización y carga del CSS necesario sólo para los bloques usados en cada página: El editor de bloques de WordPress optimiza la carga del CSS necesario sólo para los bloques usados en cada página, lo que significa que tus páginas se cargan más rápido y se reduce el tiempo de carga.
Podríamos llegar a 100 en los motivos técnicos y prácticos de la lista, pero se nos acaba el año y hay que publicar este post, o esto sería la wikipedia del editor de bloques… se viene un año 2024 en el que, el gestor de contenidos web más usado de todo internet, va a lograr por fín lo que se ha buscado siempre: Una internet más accesible y sencilla de usar para todos, y para todos los usos.
Os deseo a todos un feliz 2024 lleno de sites confeccionados «como dios manda» (o como la comunidad «ruega») 😉
Deja una respuesta