Plugins de cache, API externas y CDNs con optimizaciones

El motivo de escribir este post es que últimamente los conceptos se están mezclando demasiado.

Si ya me conoces sabrás que soy consultor WPO desde hace ya años (más de 12) y todos estos temas que tienen que ver con técnicas WPO me vuelven loco.

Me encanta probar nuevas soluciones WPO, tanto para WordPress como generales.

Pero desde hace algún tiempo, debido a que ciertas técnicas WPO requieren métodos especiales, estoy viendo que se están mezclando los conceptos de “plugin de cache”, “CDN con optimizaciones” y también que ciertas técnicas WPO se realizan de una forma poco ética.

Esto en sí no es malo, pero desorienta a muchos usuarios que no tienen conocimientos avanzados y que no distinguen si los recursos están cargando desde sus propios servidores o desde un CDN externo. Incluso es posible que no sepan dónde se realizan exactamente las optimizaciones, lo que suele dar lugar a pagar servicios difícilmente justificables.

Sí, así de primeras estoy hablando directamente de Nitropack. Aunque hay otros cuantos servicios camuflados como plugins o como partes de plugins que también se podrían dar por aludidos y de los que vamos a hablar un poco más abajo.

Incluso puedo meter dentro del mismo “saco” a todos los plugins que realizan la conversión de imágenes a WebP usando un API externa o incluso llegando a realizar la conversión al vuelo para servirlas desde un origen externo.

OJO, porque aquí NO estoy incluyendo los plugins de optimización de imágenes, ya que para eso sí que hay una razón lógica para realizar la conversión en un API externa en lugar de hacerla en el hosting de la web.

El problema de depender de peticiones externas para cargar ciertas cosas en vivo es un problema. No os podéis imaginar cuántas webs tienen un cuello de botella importante por esto.

Existen claramente dos casos donde se realiza la optimización de un recurso de forma externa:

• La optimización del recurso en cuestión requiere de mucha potencia de proceso y existe duda de si el hosting del usuario lo va a poder asumir, o bien se requieren tecnologías que un hosting normal no incluye para realizar la optimización de recursos de forma eficiente, rápida y ofreciendo un buen servicio.
• Se busca una dependencia tecnológica previo pago de un SaaS, ya sea con un plan mensual o mediante el pago por uso.

El primer caso es justificable; el segundo caso, para mí, es casi una estafa.

Como ejemplo del primer caso está la optimización de CSS no usado (Unussed CSS) de WP Rocket o incluso la optimización de imágenes mediante una API externa que hacen muchos plugins como Imagify, Kraken.io, Shortpixel, etc. Como ejemplo del segundo caso podemos hablar directamente de Nitropack, aunque esto no es exclusivo de plugins o servicios de pago.

¿Con esto a qué me refiero? Pues a que considero “confundir” al usuario utilizar APIs externas o servicios externos que canalizan la carga de recursos de nuestra web desde orígenes de terceros o realizan las acciones en servidores de terceros, pudiendo hacerlo directamente en nuestro hosting.

Sí, vuelvo a decirlo, Nitropack es el mejor ejemplo de esto, aunque hay unos cuantos más.

Para muchos Nitropack parece magia, pero realmente el 80% de lo que hace Nitropack se puede hacer en local y servirlo desde tu servidor o desde el servicio CDN que tú quieras, pudiendo prescindir de esa dependencia completa que te impone el servicio.

Actualmente, Nitropack puede darte el 90-100 de 100 en Google PageSpeed y te puede hacer mejorar en Core Web Vitals, pero esto es en parte gracias al delay de JS que pueden hacer otros muchos plugins gratuitos, como Flying Scripts de WP Speed Matters.

Para que veas que la “cruzada” no va solo contra Nitropack, precisamente considero que otros dos plugins de WP Speed Matters (el gratuito Flying Images y el de pago FlyingPress) realizan ciertas acciones que no se deberían hacer en servidores externos y se sirven mediante un CDN implementado de forma no intencional.

¿En serio es necesario depender de Nitropack y de sus planes para realizar una optimización WPO tan simple? Hablando del delay de Javascript.

Sí que es cierto que Nitropack implementa por sí mismo un CDN, pero su precio es muy superior a cualquier servicio CDN pese a que el 80% de las optimizaciones que hace Nitropack pueden hacerse con plugins.

Además, la infraestructura CDN de Nitropack no es propia ni aporta nada distinto, es CloudFlare.

Aunque Nitropack no se anuncia como “plugin de cache”, considero que es el mayor “engañabobos” que he visto en más de 12 años como consultor WPO.

El producto “All in One” no está mal, pero la publicidad es engañosa:

Eso de que Nitropack está hecho para grandes eCommerce… Como tengas algo de tráfico, tendrás que hipotecar tu casa y tu coche para poder pagar la factura de tráfico de Nitropack. Y todo por el uso de un CDN que puedes usar de forma gratuita o por 20 euros al mes (CloudFlare).

Digo esto porque Nitropack no te cobra por la optimización en sí, sino por el ancho de banda del CDN y por el nuevo de pageviews. Lo segundo puedo llegar a entenderlo, pero lo primero no.

Te pongo un ejemplo. Aquí le estoy cargando una web con 20k URL y va “optimizando” poco a poco:

La web casi no tiene tráfico, sin embargo, a ellos esa “optimización” les está saliendo más cara que muchas de las webs que tienen cargadas por el simple hecho de optimizar más URL cada día, aunque no se sirvan.

¿Qué quiere decir esto? Que te cobran por 2 características donde vas a depender más de ellos, pero no por las que realmente destacan en su servicio.

¿La razón? La puedes ver en el gif siguiente:

Nitropack no es escalable para webs con tráfico. Lo único que hace es poner un “parche” para tapar un agujero que sigue estando ahí y, encima, cobrándotelo a 50 veces el precio real.

Antes de acabar el post y ya dejando de hablar de Nitropack, voy a analizar algunas cosas de algunos servicios dando mi opinión sobre el tema.

De los plugins más conocidos de cache y optimización para WordPress, muchos tienen funcionalidades que se ejecutan fuera por las razones expuestas en este post.

Te voy a dar algunos ejemplos de plugins conocidos y otros no tanto:

• WP Rocket: Realiza la optimización de CSS sin usar mediante un API externa y devuelve los recursos al servidor, sin cargarlos desde un CDN externo. Esto posiblemente lo hace para proteger la tecnología, ya que es única. Totalmente justificable.
• Swift Performance Pro: Dispone de varias funcionalidades que pueden realizarse o no mediante una “Compute API” externa devolviendo los recursos al servidor. El usuario puede elegir. Se ofrece esta opción para que no impacte en el rendimiento del hosting. Totalmente justificable.
• Imagify, Shortpixel, etc.: Todos los plugins de optimización de imágenes realizan la compresión de imágenes con un API externa. Esto lo hacen para proteger la tecnología. Lo que no tiene sentido actualmente es hacer la conversión a WebP con un API externa, ya que se puede hacer perfectamente en local.
• LiteSpeed Cache: Es transparente. Existen ciertas acciones que requieren hacerse en el servicio externo QUIC.CLOUD, como la generación de ruta crítica de CSS y la optimización de imágenes. Totalmente justificable.
• Flying Images: Un plugin de optimización de imágenes gratuito que hace las optimizaciones pasando las imágenes por un proxy inverso / CDN. Aunque es gratuito y no está mal pensado para implementar un CDN de forma gratuita (Statically basado en CloudFlare), para optimizar imágenes es un lío innecesario, en mi opinión.
• FlyingPress: Es un plugin de cache y optimización muy bueno, pero el hecho de que para optimizar imágenes y convertir a WebP tengas que hacerlo mediante el uso de un CDN externo que las convierte al vuelo me parece una salvajada, y más en un plugin de pago (y no barato).

Aunque podría seguir detallando funcionalidades de servicios que usan recursos externos sin sentido, voy a parar aquí, ya que creo que ya me he explicado lo suficiente.

El mensaje final de este post tan “distinto” es muy simple:

Por favor, llamemos a las cosas por su nombre y dependamos de terceros única y exclusivamente cuando sea necesario. No utilicemos soluciones que realizan acciones “en la nube” cuando podemos hacer lo mismo en nuestro servidor, sin impactar en el rendimiento, sin tiempos de espera sin sentido y posiblemente de una forma más barata.