page builders angeles o demonios

Page builders, ¿ángeles o demonios?

El pasado jueves 7 de Septiembre tuve el placer de participar en un meetup de WordPress Madrid para hablar sobre Page Builders.

En primer lugar agradecer al equipo de organizadores: Mauricio, Carla, Carlos, Álvaro y Nacho, a Campus Madrid por cedernos el auditorio, y a SiteGround por patrocinar y apoyar el evento.

Y también mostrar agradecimiento a los asistentes. ¡Unas 130 personas!

La charla fue sobre page builders. Tema muy controvertido, siempre que sale a debate las posiciones suelen estar muy marcadas entre los que están a favor de su uso y los que están en contra.

Hice un pequeño repaso sobre cómo ha ido evolucionando el sector web en la última década. Hace 10-12 años había mucha segmentación entre los distintos perfiles involucrados en cualquier proyecto o desarrollo web: diseñadores, creativos, arte finalitas, maquetadores, programadores, flasheros…

Con el paso del tiempo han ido apareciendo herramientas que nos hacen la vida más fácil: CMS, frameworks, repositorios de código, plantillas, etc… Y en los últimos años han irrumpido con fuerza los page builders: Divi, Visual Composer, Elementor…

Las líneas entre diferentes perfiles en cierta manera se distorsionan. Estas herramientas permiten que los diseñadores puedan desarrollar y los desarrolladores puedan diseñar.  Espero que se me entienda, es decir, para ciertos proyectos un desarrollador no necesitaría a un diseñador si compra una plantilla HTML, y un diseñador no necesitaría un programador si utiliza un CMS e instala y configura los plugins que necesite pare resolver ciertas funcionalidades.

Son tan fáciles de utilizar que incluso personas que no tienen formación o experiencia en este sector, son capaces de obtener resultados. Aunque siempre digo que es mejor conocer la tecnología que hay por debajo de la herramienta.

Ventajas

  • Inversión económica reducida, puedes encontrarlos en una horquilla entre 35 y 170 euros
  • Fáciles de manejar, dinámicos, intuitivos y visuales. Interface drag & drop. La curva de aprendizaje es prácticamente nula
  • Multitud de configuraciones, suelen disponer de un panel de configuraciones generales donde establecer logos, paleta de colores, URL redes sociales, efectos de elementos, navegación…
  • Variedad de Módulos, los módulos son elementos que se arrastran a un área del lienzo: columnas, botones, separadores, Google Maps, acordeones, pestañas…
  • Sin una línea de código, la interfaz y las configuraciones no requieren saber de maquetación y/o programación, aunque siempre viene bien, no es estrictamente necesario conocimientos de lenguajes como HTML, CSS, JavaScript ó PHP para construir una página web
  • Reducen el coste total del proyecto, crear contenido lleva menos tiempo, lo que repercute en un coste menor del proyecto.

Inconvenientes

  • No existe una estandarización, hay tantas maneras de hacer las cosas como builders en el mercado, cada uno sigue su propio camino
  • Efecto Lock-in, dependencia absoluta. Si lo desactivas encontrarás una infección de shortcodes (Divi, Visual Composer…) ó datos de estructura serializados en post-metas (Elementor…). Migrar esto en un futuro puede ser la muerte a pellizcos
  • Se fía casi todo a la base de datos, ¿Entornos local / desarrollo / staging / producción?¿SVN / GIT?¿Despliegues?¿Integración continua?¿Test unitarios y de aceptación?
  • Desaparece el modelo de datos, todo lo que se crea va al campo post_content
  • ¿Rendimiento pobre? Históricamente etiquetados como lentos, alto consumo de recursos, muchas consultas a BBDD, tiempos de carga malos… En realidad no es tanto como la leyenda dice, pero si es cierto que ejecutan más consultas a BBDD y los recursos estáticos (CSS y JS) suelen ser pesados
  • ¿Resultados profesionales? Argumentos como la rapidez y la facilidad implican una dedicación pobre a un proyecto. Se hacen webs como churros por menos de 300 €

Conclusiones

  • Invierte algo de tiempo en pensar si son la mejor solución a tu proyecto, y piensa en el futuro
  • Ideales para landings, páginas corporativas, campañas a corto plazo…
  • Ideales para proyectos con bajo presupuesto
  • Hay que tener mucho cuidado con ellos y optimizar su uso para obtener buenos resultados
  • Huir de ellos para proyectos grandes o donde se necesite una estructura o arquitectura de datos sólida

¿ Gutenberg ?

Está previsto el lanzamiento del nuevo editor Gutenberg para la versión 5.o de WordPress. Aún es pronto para adivinar el futuro, pero todo hace indicar que marcará un antes y un después en éste CMS.

editor gutenberg

La forma en la que se creará el contenido a partir de Gutenberg cambiará de manera radical. Daremos la bienvenida a los bloques y nos despediremos de los widgets y sidebars. Probablemente los shortcodes pasen a un segundo plano.

Llegará una estandarización, será el contructor de páginas nativo y referencia para crear contenido. No obstante, tendremos que esperar.

Os dejo el enlace a la presentación aquí.

¿Te ha resultado útil esta información? 🍺

Si este post te ha resuelto un problema, invítame a un café o a una cerveza. Con este pequeño gesto me animas a seguir escribiendo.

Comentarios

3 comentarios en Page builders, ¿ángeles o demonios?

  1. Para mí, en los Page Builders, hay un antes y un después con Elementor. La gran diferencia con otros es su semántica y su limpieza (mejorable). Un problema es que otros addons ya no son ni tan semánticos ni tan limpios. Por fin le he pillado el truco a su optimización y conseguir más de 90 casi siempre en Google Page Speed, sin romper nada.

  2. Va a ser muy divertido ver cómo los editores visuales actuales van cayendo con la llegada definitiva de Gutenberg, y qué soluciones plantean para poder mantener la cuota de mercado.

    En la mayor parte de proyectos que usan un page builder, un grid de columnas en el editor y un poco de gusto es más que suficiente para solucionar el diseño.

    ¡Veremos a ver qué sucede!

  3. Yo me he encontrado, en algunos pocos clientes que lo usaban, que sucedía lo siguiente:

    – Tiempo de respuesta del servidor bastante más lento.
    – Carga de ficheros CSS y JS con mucho más código del que necesitaba cada página. Por lo que, aunque se minimizara, se uniera o comprimieran, el tiempo de carga era excesivo.
    – Lo mismo que lo anterior pero con imágenes y fuentes.
    – Había CSS y JS que eran para el uso de estos editores en la zona administrativa pero que se cargaba en la zona pública. Resultando aún más tiempo de carga.

    Estoy de acuerdo, que personalizándolo mejoran en algo. Pero eso, la mejoría sería muy poca y tendría que ser por alguien que sepa de desarrollo. Así que lo que te ahorras de contratar a un profesional por un lado, puede que termines pagándolo por otro.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *:

  • El fin del tratamiento es únicamente la moderación de comentarios para evitar spam
  • La legitimación es tu consentimiento al comentar
  • No se comunicará ningún dato a terceros salvo por obligación legal
  • Tienes derecho al acceso, rectificación y eliminación de los comentarios