La batalla por la tercera plataforma parecía ya perdida. Al menos, al nivel que esperábamos hace un par de años.
Las tecnologías web han supuesto un cambio de paradigma en cuanto al modelo de comunicación de nuestra sociedad. Son, en su mayoría, desarrollos enfocados a dotar de accesibilidad, universalidad y visibilidad cualquier contenido.
El principal problema que seguimos arrastrando, y que lamentablemente seguiremos durante mucho tiempo, es que toda la arquitectura que hay por debajo fue en su día diseñada para unos menesteres mucho menos ambiciosos.
Las tripas de internet son las tripas de un complejo sistema de compartición de documentos entre iguales, que adolece de una falta de protocolos de comunicación adaptados al feroz consumo actual, y a los posibles intereses en pos de ofuscar o monitorizar toda esa información.
El resultado final, por tanto, es un sistema que ha recibido mil y un parches. Que ha evolucionado mucho más allá de la idea que inicialmente tenían sus creadores. Que ha sufrido continuas tergiversaciones (diseños no intencionados) en su función, amparado bajo un estándar (para bien y para mal) muy abierto en cuanto a posibilidades. Y que encuentra ahora, en varios acontecimientos recientes, un impulso que se echaba en falta desde hace tiempo.
Índice de contenido
La revolución móvil… y la lentitud de Internet
En Internet hemos vivido varias crisis. Desde aquella que dio paso a la globalización, pasando por la guerra de navegadores (y estandarizaciones), la batalla perdida (al menos por ahora) de la web como plataforma, y el reciente encontronazo de la industria publicitaria con la tecnología móvil.
Y es que precisamente ha sido el mundo móvil el verdadero Talón de Aquiles de la web, al no encontrar ésta maneras más efectivas de hacerse un hueco aceptable en este escenario.
Las ansias de monetización han jugado también en nuestra contra, transformando esas primeras versiones móviles de servicios digitales, ligeras, de poco consumo y ultrarápidas, en auténticos agujeros negros de rendimiento, usabilidad y gasto de batería. Unas páginas repletas de scripts de monitorización, que intentan cargan contenido en diferentes hilos, bajo una arquitectura que no se presta a este tipo de conexiones.
La mayoría de usuarios quizás no se den cuenta, pero prácticamente la aplicación que más batería gasta en sus smartphones (quitando juegos y visionado de vídeo, claro está) sigue siendo el navegador, puesto que por la propia idiosincracia de los lenguajes web y de la arquitectura web, es necesario que esta aplicación “interprete” (y no simplemente muestre) el contenido que tiene que recopilar de cientos de consultas distintas. Esto una y otra vez, con cada página, con cada actualización de la web.
La respuesta de la Comunidad es por tanto clara y concisa. La web tal y como la conocemos debe evolucionar en busca de ese equilibrio que antes sí teníamos, y sobre todo, debe hacerlo en el apartado móvil, donde los recursos son menores y más críticos que en escritorio.
Así, veíamos movimientos interesantes, como la definición (aún en pañales) de un nuevo estándar de desarrollo enfocado a móviles, fuertemente restrictivo. Ya no se trata de meter cuantas más cosas mejor en la web, sino de incluir únicamente aquellas cuyo gasto (en recursos energéticos, en peticiones) sea el mínimo posible, y repensar la necesidad (y viabilidad) del resto.
Apaños como los que en su día implementé en esta página, y expliqué en varios tutoriales, van alineados con esa cada vez más necesaria optimización de tecnologías. El uso de CDNs y demás proxis inversos para “acercar” el contenido al visitante lo máximo posible, el cacheado de páginas dinámicas para reducir en la medida de lo posible el gasto de recursos del servidor, y la paralelización de carga de imágenes, unida a la optimización del apartado gráfico de la web, a la reducción y síntesis del contenido mostrado en móviles.
Todos movimientos a los que ahora se suman varios otros, y que como veremos, quizás acaben por devolverle esa inmediatez que echamos en falta al compararlo con el mundo app.
Tres movimientos de la industria en favor de la inmediatez de la web
CloudFlare habilita HTTP/2
En su día definí el HTTP/2 como “el cambio más brutal que Internet iba a sufrir en los últimos años, y que para colmo, ocurría de forma totalmente abstracta al usuario“.
Hablamos de cambiar “el asfaltado” de todas esas carreteras donde ahora están circulando los datos. De actualizar un protocolo que es crítico en toda comunicación web que se haga, y que lleva sin tocarse desde hace 17 años.
El empaquetado de peticiones por cliente, el pre-almacenado nativo que ofrecerá, y el cifrado de las comunicaciones, son tres de las novedades que incluye este nuevo protocolo, que ya está disponible para cualquiera, y que únicamente encuentra barreras en su expansión no en su compatibilidad con tecnologías anteriores (es retrocompatible con HTTP, así que podemos estar tranquilos), sino en la tardanza que históricamente tienen en implementar este tipo de cambios las operadoras y los proveedores de servicios.
La semana pasada, CloudFlare, presente en más de cuatro millones de páginas (esta incluida), habilitaba por defecto HTTP/2 para todos sus clientes (EN). Y simplemente con esto, de golpe, en el ranking de webs más visitadas de Alexa, aumentaba un 75% el número de webs con HTTP/2 habilitado.
Es decir, a efectos prácticos, se ha doblado el número de webs con HTTP/2. El doble de páginas que ahora cargan sustancialmente más rápido.
PHP7 ya disponible
El pasado jueves, la versión 7 de PHP se hacía pública (EN), y ya estaba disponible para su uso por cualquier interesado.
PHP, que es el lenguaje presente en el 70% de la webs que habitualmente visitamos, obtiene así, sin que de nuevo el usuario tenga que hacer nada, un conjunto de novedades que le hacen prácticamente poder realizar consultas el doble de rápido (al menos el doble de rápido que PHP 5.6, la versión más utilizada en la actualidad).
Por parte de los administradores, un trabajo de actualización a la nueva versión, dependiente también normalmente del proveedor de hosting.
WordPress API Rest
Y termino con WordPress, el CMS presente en una tercera parte de todas las webs mundiales (y que también está desarrollado en PHP), se actualizaba hace escasas horas, como comentaba la semana pasada, a una nueva versión, y con ella, llega de forma nativa el API Rest.
No me voy a extender mucho en esto ya que para ello le he dedicado recientemente un artículo, pero por resumir, significa que con el cambio podrán surgir desarrollos hiperoptimizados a escenarios como el móvil o necesidades muy específicas (un portal web, un foro, un blog) sin tener que cargar para ello el resto de elementos de WordPress.
Una nueva parametrización que no hace más que mejorar la inmediatez del contenido.
Justo lo que necesitaba la web para volver a plantar cara en el escenario tecnológico actual.
Ahora falta que estos cambios acaben por tardar poco en llegar. Por mi parte, sigo pendiente del proveedor de hosting para migrar a ese PHP7 que tan buena pinta tiene, y espero esta semana liarme con CloudFlare por ver qué cambios necesito hacer en verdad para tener correctamente habilitado HTTP/2, al menos en la parte que controla el CDN.
Muy interesante como siempre!
Muchas gracias _PeLUsA_ :).
Muy interesante Pablo. Sobre el http/2, supongo que requiere actualizaciones y cambios en el servidor web pero, ¿requiere cambios en la programación del sitio web para aprovechar las mejoras? Un saludo.
A nivel de programación, que yo sepa no. Es un cambio de protocolo de comunicación, y por tanto, dependiente de cómo el servidor entrega los paquetes.
Se supone una mejor respuesta del servidor dependiendo de la plataforma (no carga elementos de escritorio si la petición viene móvil) o al menos eso entiendo en términos mortales.
Además monopoliza peticiones al servidor, a diferencia de HTTP que hacia varias y constantemente lo hace. ¡Es básicamente lo que se habla o se dice!
Con HTTP tienes que hacer cada petición por separado. De hecho para solventar este pequeño problema se recurren a engaños como el Domain Sharding, haciéndole creer al navegador que debe cargar diferentes recursos de diferentes dominios cuando realmente todo está apuntando al mismo.
HTTP/2 solventa este problema de raíz permitiendo conexiones simultáneas. Algo que hace 20 años no era necesario (las webs eran muy sencillas) pero que hoy en día es lo más habitual.