El sábado pasado, recorriendo alguna red social, me topé con un post titulado “Cómo armar tu sitio o tienda online en 4 pasos”. Sorprendido ante la promesa de un tutorial tan simple para un proceso que suele ser enrevesado, no pude sino rendirme ante el clickbait.

Los pasos en cuestión serían:

1. Contratar un hosting + dominio.

2. Instalar Wordpress y un tema de WP.

3. Instalar un constructor de páginas.

4. Cargar el contenido.

El primer paso es evidente. En el segundo, pueden surgir algunos problemas. Mientras la enorme mayoría de los proveedores de hosting ofrecen instaladores de Content Management Systems como Wordpress, la elección del tema requiere un ojo un tanto entrenado. Es fácil elegir un tema porque es el que más se acerca a la idea del sitio que uno tiene en su mente. Pero elegir un diseño sólo porque sus demos cumplen con nuestros deseos estéticos no es ideal.

Si bien es comprensible que este sea el criterio de alguien que no es un diseñador/desarrollador, y por lo tanto no va a poder adaptar el diseño más allá de lo que el panel de personalización le permita, falla en considerar cuatro factores muy importantes:

• Calidad de código, ¿El código cumple con los estándares de mejores prácticas de WP? ¿Es fácil de debuggear?

• Documentación, ¿El tema está bien documentado? ¿Hay una base de tutoriales, textos explicativos y comentarios sobre particularidades del tema? ¿Hay un foro de ayuda/discusión? Esto es especialmente importante si vamos a pagar por nuestro diseño.

• Peso, ¿El tema está cargado de librerías que van a dilatar el tiempo de carga del sitio?

• SEO, ¿El sitio genera código HTML5 válido que pueda ser rastreado por los robots de motores de búsqueda?

Muy a menudo, diseñadores y no-diseñadores alike se dejan seducir por la promesa de temas “multifunción”, que pueden ser convertidos en casi cualquier sitio para casi cualquier propósito, deben esta capacidad a multiples y extensísimas hojas de estilo. Infinitas posibilidades, infinito código. Infinito código, un tiempo de carga infinito.

Si además de un tema mulfiunción, vamos a usar el constructor de páginas, el problema de “infinitas posibilidades, infinito código” va a duplicarse.

¿Qué es un constructor de páginas?

Los “constructores de páginas” (“page builders” o “website builders”) son plugins precargados con una serie de elementos de diseño, que podemos combinar entre sí y personalizar para construir páginas sin la necesidad de tocar código. Uno de los constructores de páginas más populares es Elementor, pero dista de ser el único.

Por qué usar un constructor de páginas

Los constructores de páginas pueden permitirle a diseñadores visuales que no codean diseñar sitios a su gusto, e incluso insertarse en el rubro. También pueden ser útiles para ONGs, individuos y pequeñas empresas que necesitan un sitio web pero no cuentan con los recursos para contratar a un especialista.

El mayor (si no el único pro de los constructores de páginas) es que pueden bajar la barrera de entrada de Wordpress. Barrera de entrada que ya estaba al raz del piso - y esa es una de las grandes cosas que tiene Wordpress.

Por qué no usar un constructor de páginas

Pero, por supuesto, la premisa de este correo es “Por qué no deberías usar Constructores de Páginas en Wordpress”. A mi parecer, los cons de usar cosntructores de páginas son cuatro, y superan por mucho al pro.

Dependencia

Los constructores de páginas causan dependencia. Digamos que nuestro constructor de páginas viene con un tema y que queremos deshacernos de él, por X razón, o que la empresa que hizo y mantiene nuestro constructor de páginas necesita que comience a hacerles más dinero, y va a limitar las funciones que antes ofrecía gratuitamente, o que de repente queremos hacer algo con el sitio que nuestro actual constructor no permite. La consecuencia de cualquier de estos cambios, como bien notó un colega, va a ser esto:

Esos shortcodes le decían a nuestro constructor de páginas qué propiedades debía tener cada uno de nuestros elementos quedarán allí, donde nuestro hermoso diseño solía estar, desnudas, explícitas, sin ningún plugin con el que comunicarse.

Por otra parte, como el colega también nota, la desactivación (ya sea intencional, cuando se está intentando rastrear el origen de un problema), como involuntaria, puede tener como consecuencia un error fatal cuando se reactiva el plugin.

Tiempo de carga

Ya lo dijimos hace algunos párrafos: Código infinito, tiempo de carga infinito. Tener cantidades grotescas de código cargando hincha al sitio, mete a un colibrí en un disfraz de mamut. Y la cantidad de código de los constructores de sitios es definitivamente grotesca. Por ejemplo, Fusion cuenta con 70 componentes con más de 300 variables posibles. Todo eso está latente en el sitio todo el tiempo. Eventualmente, Fusion tuvo que introducir una función para que el usuario pueda desactivar los elementos que no está usando en su sitio.

SEO

Más allá de potenciales torpezas en cómo el constructor de sitios estructure el contenido, afectando cómo los robots (y los lectores de pantalla) leen el sitio, no perdamos de vista que el tiempo de carga afecta la posición de nuestro sitio en los motores de búsqueda.

¿Hay alternativa?

Elementor y demás constructores de páginas pueden ser infinitamente útiles para usuarios que no estén entrenados en diseño. Pero deben ser usados con cuidado, y entendiendo sus potenciales drawbacks.

Gutenberg, el nuevo editor de Wordpress es una alternativa (albeit limitada) a los constructores de páginas, y no tiene problemas de compatibilidad, ni de SEO ni de peso. Incluso podríamos decir que Gutenberg le puso una fecha de caducidad a los constructores de páginas.

Gutenberg es más que suficiente para crear páginas funcionales, con embeds, con elementos bonitos como slideshows, etcétera. Si algo no puede hacerse en Gutenberg, probablemente necesite ser codeado.

Más allá de la idea de que el código es poesía, etcétera, etcétera, hay algo innegable: Los distintos lenguajes de programación son idiomas en los que le hablamos a las máquinas y les pedimos que hagan cosas. Desde “Que este botón sea azul” hasta procesos complejos que tomaría una parrafada siquiera explicar. En todo caso, cuando de crear sitios se trata, el código es un mal necesario. Si vos no le estás hablando a la máquina y pidiendole lo que querés, y le estás delegando ese diálogo a una interfaz, no sabes en qué términos se está teniendo esa conversación. Y los “interpretes” de los deseos graficados de un usuario que no codea suelen tener estas desventajas. Podría decirse que usar constructores de páginas y otras soluciones drag & drop es equiparable a usar Google translator para mediar una conversación.

Bah, ya descendí en la locura. ¿Tenés alguna duda, inquietud o comentario sobre crear sitios en Wordpress? Sentite libre de responder este email.

Un saludo,

Aaron de Postdigitalist