Este artículo sobre Javascript no pretende ser más que una reflexión con conclusiones finales sobre algo que esta ocurriendo en la actualidad en Internet, algo que suelo explicar en mis ponencias para intentar explicar “hacia dónde” se dirige el WPO actualmente.
1 – Cuota de uso actual de Javascript en Internet
Vamos a empezar por el principio de todo esto, ya que es necesario ponerse en contexto para entender perfectamente el problema.
Ahora mismo, Javascript es la tecnología client-side más utilizada en Internet, con una cuota de mercado que superaba el 95% en enero de 2020. Su competidor más cercano es Flash (el antiguo Flash, sí) con una cuota de mercado del 2,8%. Como puedes observar hay diferencia, ¿no?
Otras tecnologías client-side que existen, además de Javascript y Flash, son Silverlight y Java. No obstante, sus cuotas de mercado no superan ni el 0,1%.
Creo que no necesitamos ninguna gráfica ni ser matemáticos para entender que actualmente Javascript lo es TODO debido a la cuota de mercado: el 95% de las webs del mundo usan Javascript.
Y hay algo más que debemos tener en cuenta: este porcentaje solo marca la cuota de mercado de Javascript como tecnología client-side, pero también está Node.JS con una cuota de mercado inferior al 1% en el mercado de los servidores web y que es Javascript en server-side.
Siguiendo con Javascript como client-side, tenemos otro dato que también nos da a entender la enorme cuota de mercado que tiene Javascript actualmente.
Existen distintas librerías Javascript que se suelen utilizar para desarrollar interfaces y funcionalidades dinámicas con Javascript en sitios web. La librería Javascript más utilizada en Internet es jQuery, con una cuota de mercado tan bestia que el 75% de las webs de todo Internet usan jQuery. Por detrás de jQuery esta Bootstrap, que supera el 20%, y Modernizr con un 10%.
Casi el 98% de las webs que usan Javascript en client-side usan jQuery, por lo que podemos decir que jQuery es el único extendido.
Para que veas lo que digo, WordPress trae jQuery para usar en themes, plugin y en su propia interfaz.
Vale, creo que ya puedes entender la magnitud de todo esto y la cuota de mercado de Javascript y jQuery en 2020.
2 – El abuso de Javascript en themes multipurpose
Aunque menciono themes multipurpose, la verdad es que no solo me estoy refiriendo a themes para WordPress, sino también a themes multipropósito que existen para todos los CMS más usados y que todos conocemos.
Con Javascript podemos darle a una web funcionalidades dinámicas muy atractivas para el usuario y eso teóricamente es bueno para la experiencia de usuario, pero… ¿qué coste tiene esto?
Esto es lo que quiero que entiendas: cada funcionalidad implementada con Javascript en un front-end tiene un consumo de recursos en la interpretación por parte del navegador del visitante. Este es precisamente el problema.
La posibilidad de implementar un slider o un accordion usando un par de clics desde el pagebuilder del theme consume recursos en el navegador del visitante al cargar.
La posibilidad de implementar un menú hipermegachulo y personalizable usando un par de clics desde las opciones del theme consume recursos en el navegador del visitante al cargar.
La posibilidad de configurar un carrito dinámico en tu tienda online (que se añadan los productos sin recargar la página) consume recursos en el navegador del visitante al cargar.
Como has visto, en los tres puntos anteriores siempre he dicho “la posibilidad de” y es que el consumo de recursos no ocurre por algo configurado específicamente, sino también por todo lo que hay que cargar para que tú puedas configurar esas funcionalidades desde tu panel de control de forma visual con un par de clics.
El navegador del visitante es el problema porque no lo podemos controlar. No podemos controlar ni el software ni el hardware que utiliza el visitante para acceder a nuestro sitio web, por lo que debemos hacer que una web cargue rápido SIEMPRE, independientemente de que el hardware sea low-cost o que el navegador web no esté actualizado.
El punto crítico del WPO está en los móviles. La batalla del WPO se libra en esta área de “reciente” aparición y rápida expansión.
Como digo, aquí el problema lo encontramos en los dispositivos móviles, ya que existe una gran diferencia entre el rendimiento que podemos conseguir al ejecutar Javascript en un iPhone X y el rendimiento que podemos conseguir en un Xiaomi Redmi 6A de gama baja.
En ordenadores portátiles y de sobremesa no existe este problema, ya que el listón de rendimiento está más alto. No es común encontrarse muchos procesadores de baja potencia y bajo consumo como el Intel Atom, ya que su cuota de mercado no es lo suficientemente alta. En cambio, es posible encontrarse dispositivos móviles de gama baja, ya que su cuota de mercado es muy alta.
Sin enrollarme mucho más, a continuación te dejo este gráfico de rendimiento de Javascript ejecutado en distintos dispositivos móviles, tablets y ordenadores para que veas la diferencia.
(Cuanta más alta la puntuación, mejor)
Estas pruebas están realizadas personalmente por mí, utilizando los distintos dispositivos que puedes ver en la gráfica y el benchmark browserbench.org utilizando siempre Google Chrome 76.
Como puedes ver en la gráfica anterior, existe muchísima diferencia en potencia entre un ordenador de sobremesa o portátil con un i9 9900K y un smartphone de gama baja Xiaomi con un Qualcom Snapdragon 625. Además del procesador, en estos casos también influye la memoria RAM disponible y el tipo (DDR2, DDR3, DDR4, etc.).
Incluso aunque el hardware sea el mismo, la puntuación de proceso de Javascript varía dependiendo del navegador utilizado en cada caso:
(Cuanta más alta la puntuación, mejor)
NOTA: He intentado hacer el benchmark con Internet Explorer 11 y también con Internet Explorer Edge, pero no he conseguido completarlo con ninguno de los dos por problemas de compatibilidad.
Volviendo al tema. Debemos tener en cuenta esto cuando planificamos el diseño o desarrollo de una web y siempre debemos intentar que la web cargue rápido y de forma fluida incluso cuando el usuario tiene un hardware low-cost o antiguo. También debemos tener en cuenta que un sitio web muy sobrecargado puede llegar a bloquear dispositivos con hardware poco potente o navegadores web ya colapsados que funcionan en hardware poco potente.
Pero hay algo más: los navegadores de los clientes no son los únicos que descargan e interpretan el Javascript de una web. Los bots de los principales buscadores como Google también descargan e interpretan los JS al crawlear la web.
Y esto se puede apreciar en gráficas como esta:
Aunque es una gráfica antigua (2016) del antiguo Google Search Console, sigue siendo factible a falta de que esta característica completa se integre dentro del nuevo Google Search Console.
Si conseguimos agilizar la carga de Javascript tanto en la descarga como en la interpretación, podemos estabilizar y bajar los tiempos de rastreo de los bots. Así mejoraremos el WPO de carga a Google, mejorando así el SEOonpage del sitio web.
En sitios web muy complejos y con muchas funcionalidades y Javascript, podemos conseguir mejoras importantes con la optimización de JS. Entonces, ¿por qué no se hace? Pues porque en themes multipurpose, como los más vendidos en ThemeForest, es muy difícil realizar optimizaciones importantes debido a las dependencias y la estructura de archivos compleja.
Por eso, en el caso de WordPress recomiendo desarrollar con mi solución modular favorita: Hello Elementor + Elementor PageBuilder o GeneratePress + Elementor PageBuilder.
3 – Optimización de Javascript y soluciones
En este blog ya he planteado soluciones para la optimización del Javascript en WordPress, pero también he dicho en diferentes ocasiones que no existen milagros.
Si consigues optimizar un 50% el Javascript de un theme multipurpose como Avada, The7, Enfold o cualquiera de los más vendidos, sin tocar código, pues creo que ya puedes estar contento.
La solución más “eficiente” para conseguir mejoras como las que has visto en esta imagen de cara a Google es poner en la balanza lo que necesitamos y lo que no:
Para ponerte un ejemplo: existen plugins de carga condicional para WordPress como Perfmatters que te permiten elegir dónde, cuándo y cómo cargar los JS y CSS, para que no tengas que cargarlos en cada página del sitio web, aunque realmente no los necesites.
Hablo de Perfmatters porque para mí es el más intuitivo para configurar carga condicional de elementos, pero evidentemente existen más y también se puede hacer de forma manual con código en el functions.php del theme activo.
¿Qué desventajas tiene la carga condicional? Pues que, si es un sitio muy cambiante, vamos a tener que mantener actualizados los listados de exclusiones vigilados. Por otro lado, en themes muy complejos, es imposible conseguir mejoras con la carga condicional debido a que los “elementos” están todos metidos en un único archivo CSS o JS muy pesado y tendríamos que excluir el archivo entero, con el consecuente problema de dependencias.
Pero la verdadera solución para no tener problemas de saturación por Javascript es planear el desarrollo y diseño web desde el punto de vista del WPO y las buenas prácticas, algo que actualmente, el 99,99999% de implementadores de CMS no tienen en cuenta porque no tienen ni idea.
Algo que para el diseñador o implementador puede ser una ventaja por la agilidad a la hora de finalizar el proyecto y con el consecuente abaratamiento de costes, puede ser una “patada en la boca” para el cliente final, ya que tendrá una web que no es viable al tenerse en cuenta las nuevas tendencias.
En este caso, se aplica exactamente lo mismo que digo que hay que hacer para mejorar la seguridad de WordPress: prevenir.