Editores visuales de WordPress: acortamiento del ciclo a toda costa

Últimamente, se han puesto muy de moda una serie de editores visuales para WordPress, generalmente acompañados de sus correspondientes plantillas con cierta sofisticación. Hablo de cosas como Elementor, UX Builder o Avada Website Builder.

Sobre el papel, son una gran idea: Permiten desarrollar y mantener una web con una cantidad mínima de conocimientos técnicos, ahorran esfuerzo y el ciclo de desarrollo y puesta en producción es cortísimo: En cuanto se termina de editar, se pulsa el botón de actualizar y ,¡bam!, ya está vivo el cambio. Sin subir nada por FTP, sin lidiar con la diferencia entre el entorno de desarrollo y el de producción, sin esperar… Y sin pensar.

Existen varios motivos de peso por los cuales los proyectos grandes se desarrollan y prueban, primero, y luego se “suben” a producción. Está la necesidad de coordinar un equipo multidisciplinar, por supuesto; también cuanto más complejo es un proyecto, más pruebas requiere para maximizar las probabilidades de que al ponerlo en marcha vaya bien (a quien haya querido leer “garantizar” en lugar de “maximizar las probabilidades”, le recomiendo mejor una lectura de Lewis Carroll). Pero hay una que se aplica por igual a proyectos pequeños y grandes: Las herramientas que se requieren para crear y mantener proyectos web, no son las mismas que las que se requieren para mantenerlos en línea.

Para crear y mantener proyectos web, se necesitan potentes editores de, dependiendo del trabajo, CSS, HTML, JS, PHP, imágenes, vídeos… Y un servidor web pequeñito, que puede correr incluso en el portátil de los desarrolladores, para ir viendo qué tal queda lo que vamos haciendo.

Para mantener proyectos web en línea, se necesitan potentes servidores web que sirvan los ficheros lo más rápidamente posible, ejecuten el código (si lo hay) lo más rápidamente posible, filtren el tráfico malintencionado lo más posible y, en general, escalen mucho y bien.

El problema viene con el razonamiento siguiente: Si el proyecto es pequeño, el diseñador es solamente uno, ¿qué más da hacerlo ya directamente en el servidor?

Así a bote pronto, es un razonamiento al que no se le pueden poner muchas pegas: No hay más gente con que coordinarse. Los editores visuales vienen frecuentemente con una “cadena” completa de herramientas y recursos que incluye no solamente el editor, sino también un tema (que se puede personalizar), así como opciones adicionales para añadir elementos a la web. Todo ello, por un precio módico y solo hay que instalar un plugin en WordPress. Suena perfecto: Todo ventajas, cero inconvenientes.

O al menos, así sería si no fuera por un pequeño detalle: Esos editores visuales son horriblemente pesados.

Ya un editor visual potente “de sobremesa”, es decir, una aplicación que podemos ejecutar en nuestro PC o Mac, tiene un coste en recursos (memoria, procesador, espacio) nada trivial. Pero un editor visual de sobremesa está optimizado para correr en nuestro sistema operativo, escrito en un lenguaje compilado (léase: rápido) y lo ejecutamos localmente (vamos, aquí mismo: sin latencia, prácticamete). Por contra, un servidor que corre WordPress necesita un editor escrito en PHP: Interpretado y con la red por en medio. Por tanto, más costoso de ejecutar, para empezar a hablar.

A los servidores, optimizados para servir páginas y ejecutar código PHP, les resulta muy costoso ejecutar la enorme cantidad de código que requieren los editores de este tipo. Un servidor cloud con dos corazones de procesador moderno y dos gigas de RAM, capaz de servir docenas de miles de visitas diarias a una web sin despeinarse, cae de rodillas editando un solo artículo. Y la culpa, por supuesto, es del servidor.

¿Y qué hacemos con esto? Bueno, lo primero es que todos los implicados comprendan en qué consiste el problema. No es que su servidor esté infradimensionado o sea inadecuado para la web que se trata de poner en línea. Para lo que es inadecuado, es para editarla con un editor visual muy potente y muy mono, pero muy pesado, que se encontraría más o menos en su salsa en un ordenador de sobremesa con cuatro corazones de procesador y 8 gigas de RAM que no está haciendo nada más, pero que en un servidor cloud con la mitad o la cuarta parte de recursos, se arrastra.

Entendido esto, las posibilidades son dos:

  • Ampliar el servidor cloud a un nivel de recursos suficiente para ejecutar el editor. Lo cual, en la experiencia del que suscribe, no baja de seis corazones y cuatro gigas de RAM. Temporalmente, tal vez, mientras se termina de editar la web… Si es que se termina algún día.
  • Ir a un ciclo de desarrollo más metódico, en que el editor se quede en el entorno de desarrollo (vamos, en el portátil del desarrollador web) y al servidor se le “suba” el resultado, pero no se le cargue con la edición.

Como bonus, algún lector informado estará pensando: ¿Por qué en un servidor compartido en un cloud medianejo, el editor en web funciona sin problemas, y sin embargo al llevarlo al flamante (y más costoso) cloud dedicado a ello, ni termina de arrancar?. La explicación es bien sencilla: Los servidores compartidos, generalmente, van bien servidos de corazones y de memoria porque se les ponen a ejecutar cientos de webs a la vez. Y el uso que hacen los editores visuales de estos recursos, aunque son muchos los recursos que usan, en el tiempo son parecidos a ráfagas: Cargan mucho, pero solamente unos segundos. Así que durante unos segundos, utilizan mucho más que su parte alícuota del servidor compartido, pero como el servidor compartido va tan dotado de recursos, no se llega ni a notar. Un servidor dedicado, optimizado para la tarea que tiene que ejecutar, no va tan sobrado de recursos, especialmente en ráfaga; y ese es el momento en que se da de bruces contra el límite de los mismos.

La solución técnicamente correcta y óptima en costes a este problema es “subir” al servidor solo lo que necesita el servidor para servir la web. En la práctica, que cada responsable de una web tome su decisión.