Hace ya tiempo que construí mi primer sitio web, de carácter personal, cuando estaba en secundaria. En aquellos tiempos existían algunas prácticas que, aunque la cantidad de usuarios de Internet no era tan elevada como en la actualidad, algunos servicios en Internet y sitios web podían acaparar una cantidad muy signficativa de visitas donde los servidores, mucho más modestos que los de ahora, podían aguantar la carga de tantas visitas simultáneas. Hablamos de cómo hacía un Pentium de poco maś de 100 MHz para aguantar tanto y de por qué ahora no podría hacer lo mismo.

HTTPS no era común al principio

En los primeros tiempos cuando lo implementó Netscape, el uso era bastante exclusivo por parte de algunos bancos y sitios para realizar pagos por lo general. Los certificados SSL/TLS resultaban obscenamente caros. Adicionalmente, los procesadores no tenían instrucciones optimizadas para realizar operaciones de cifrado, por lo que su capacidad era bastante limitada y se solía utilizar solamente cuando era estrictamente necesario. Hoy en día los procesadores no tienen este problema, tienen instrucciones aceleradas por hardware que facilitan esta operación. La aparición de TLS 1.3 simplifica y agiliza el proceso de negociación, así como nuevos mecanismos criptográficos más eficientes.

Por otra parte, anchos de banda mucho más modestos y sobre todo la elevada latencia en la comunicación, sumado a la ineficiencia de HTTP/1.0 y HTTP/1.1, que comparados con los actuales HTTP/2 y HTTP/3. Estos últimos por lo general requieren HTTPS. La única ventaja que tenía HTTP era requerir menos proceso en el servidor pero tenía otros inconvenientes, sobre todo si se mantenía abierta la conexión, requiriendo más memoria RAM mantener más conexiones abiertas, mientras que por HTTP/2 solo se requiere una conexión.

Las páginas con todo dinámico no eran la norma

Este punto es más importante de lo que parece. Cuando se tiene que servir ficheros que no requieren interpretarse en el servidor, por ejemplo, un documento HTML, el servicio HTTP lo tiene mucho más fácil. Sin embargo, si se desea cargar una página dinámica, el servidor tiene que invocar a un proceso secundario, estos suelen utilizar un intérprete que procesa y construye el documento de salida, como pueden ser las aplicaciones por CGI.

Las páginas dinámicas son aquellas que varían dependiendo de ciertas variables o consultas por parte del cliente web. De estos procesos se encargaban servicios como scripts ColdFusion, Perl, PHP, Java, binarios, etc. Estos procesos consumen gran cantidad de recursos del servidor. Hoy en día es muy común tener uno de estos sistemas dinámicos corriendo para todas las operaciones que presenten HTML en el sitio, a modo de controlador frontal. Sin ir muy lejos, el típico index.php de cualquier sitio hecho en WordPress.

Lo de tener un controlador frontal dinámico obviamente no siempre fue así, porque dispararía el gasto en servidores. Y sin embargo el diseño de los scripts gestores de contenidos con un controlador frontal se impuso a finales del siglo pasado. Para mitigar la sobrecarga se ha agregado todavía más complejidad a la estructura, con sistemas de cache. Cargas dinámicas mediante XMLHttpRequest de bloques parciales de los sitios. Esto era especialmente popular para reducir la latencia de las consultas cuando todavía existía HTTP/1.1.

En esos años de transición a una web más compleja aparecieron bastantes optimizaciones a modo de parche, como obtener datos en paralelo cuando se alcanzaba el límite de conexiones de HTTP, o reducir la cantidad de ficheros a descargar mediante técnicas como los “sprites CSS” para las imágenes, o los empaquetadores de ficheros CSS y JS todo en uno, con herramientas todavía más complejas como Webpack, por decir una. Este tipo de flujo de desarrollo es heredero de un montón de optimizaciones que ya no son necesarias en la práctica con HTTP/2. Y a pesar de ello hay montones de sitios que todavía utilizan HTTP/1.1, o los que usan HTTP/2 todavía realizan estas complejas optimizaciones de empaquetar todo.

Esta herencia de empaquetar impide realizar cambios rápidos a alguno de los componentes CSS o JavaScript sin tener que volver no solo a re-empaquetar todo, sino causando la descarga de una nueva versión de un paquete enorme de hoja de estilo o script solo para un pequeño cambio. Si fueran ficheros sueltos, existiendo cache de navegador se encargaría de descargar solamente los que se hubieran modificado si el tiempo de Last-Modified es suficientemente corto o si el servidor devuelve HTTP 304 en los no modificados, algo bastante eficiente de consultar por HTTP/2. Pero con estos paquetes enormes se dificulta todo esto.

Simplificar es posible

En el pasado existía un diseño bastante común y eficiente que se ha perdido bastante: páginas estáticas HTML y algunas partes dinámicas, por ejemplo, un script buscador.php y un librodevisitas.php era algo que podía encontrarse. El script buscador consultaría una base de datos que habría indexado los documentos de la página en una base de datos y devolvería resultados basados en palabras de búsqueda. El libro de visitas actualizaría un HTML estático al enviar un formulario.

Hoy están bastante de moda los generadores estáticos de sitios web. Sin embargo es común ver cómo sacrifican el sistema de comentarios, como si el hecho de ser una página estática lo impidiera, o bien lo delegan a terceros con sistemas de discusión con implicaciones de privacidad. Pero existe un término medio que se ha perdido con el tiempo y es lo que se propone aquí.

Si nos fijamos en el funcionamiento de un sitio como por ejemplo un blog, en lugar de tener un controlador frontal con un index.php podría ser todo generado estáticamente y actualizado mediante un admin.php que genere las páginas en HTML estático. En cuanto a los comentarios, un comentarios.php regenera los HTML estáticos en su bloque de comentarios. Luego un buscador.php sabe qué ficheros estáticos contienen las palabras, cuya base de datos se actualiza cuando se regeneran por parte del admin.php.

Lo que está claro es que no se requiere un controlador frontal que constantemente está evaluando código, porque las visitas no suelen requerir mostrar información a medida en cada consulta. El ahorro de proceso permitiría servir grandes cantidades de datos con servidores realmente modestos y encima sin configuraciones complejas, además del añadido de tener menos puntos de ejecución insegura de código por parte de usuarios no administrativos del sitio.

Lamentablemente, no hay una tendencia entre tantísimos gestores de contenidos de eliminar el controlador frontal y pensar primero en estático como hace más de dos décadas. Quizás haya que crear uno propio, aunque sirva como modelo para futuros desarrollos de terceros.