¡Hey qué pasa lector! Cómo avanza ese más que probable caluroso mes de agosto. ¿Aún así tienes ganas de SEO? Pues prepárate, porque hoy venimos bastante fuerte 😉
Sigo con mi misión de hacer grande el SEO, de hacerlo llegar a más y más gente y en ese largo camino a veces tengo la suerte de cruzarme con personas de mucho talento.
Hoy viene a publicar al blog como autor invitado de verano uno de los referentes de SEO técnico de nuestro país, Carlos Sánchez (no le pongo enlace, que él ya se ha puesto unos cuantos debajo, jajaja) 😛Bromas aparte, vamos a tocar en profundidad un aspecto del SEO on page en el que podrías trabajar hoy mismo si quisieras y muy posiblemente tendría un impacto positivo en tus rankings o en el de tus clientes: el WPO o cómo hacer que tu web vuele a ojos de Google, cual M4 Competition ¡perdón! 😅 quería decir «cual avión» ✈️
Un post para guardar en favoritos y, en definitiva, un artículo para valientes, porque según vayas bajando irás aprendiendo más, pero Carlos irá subiendo el nivel.
Hoy SEO técnico en DeanRomero.com.
Vamos al lío pues. Te dejo con él.
ÍNDICE DEL ARTÍCULO
Cuando se habla de SEO Técnico uno de los aspectos que más resuena, se solicita o llama la atención es el WPO (Web Performance Optimization).
Es decir… mejorar la velocidad de una página web .
La realidad es que si bien es un factor que afecta al posicionamiento web tanto de forma directa (medición por las Core Web Vitals) como de forma indirecta (comportamiento del usuario), no es la parte de SEO técnico más importante, aunque tendrá impacto si se trabaja bien.
Sin embargo, sí que es de los aspectos más visibles y apreciables para cualquier usuario, tenga o no conocimiento sobre webs, ya que todos sabemos ver si una web es cómoda o incómoda (lenta) a la hora de navegar.
El objetivo de esta publicación es aprender a medir y analizar realmente la velocidad de tu página web e interpretar la información correcta para determinar si se deben, o no, tomar acciones y qué acciones son esas.
Como punto de partida, lo primero que debemos entender es cómo mide Google la velocidad de nuestra página web.
Vamos a intentar entender primero el WPO con «los ojos» de Google 👀
Core Web Vitals y cómo mide Google la velocidad de una web
Hay muchísima desinformación de cara a saber si una web es rápida o no a ojos de Google y esto se debe a la herramienta PageSpeed Insights, que si bien es muy completa, la gente no sabe interpretar de una forma correcta.
El círculo con el numerito y el semáforo de PageSpeed Insights no sirve para medir la velocidad de una web, sino para tener una estimación de unas posibles mejoras a partir de un checklist genérico en la herramienta de Google que puede o no repercutir en la mejora de la velocidad. Tener un 0 o un 100 no repercute en nada al SEO ni a la velocidad de tu web. — Carlos Sánchez
Aquí, en esta página donde te encuentras ahora (DeanRomero.com), podemos observar que hay un 82 de rendimiento.
¿Eso es bueno o es malo?
En sí mismo no tiene por qué repercutir en nada, solo nos indica posibles puntos de mejora y el análisis particular de nuestra web, pero Google no selecciona una carga particular para medir la velocidad de nuestra web, sino una muestra suficientemente representativa de los usuarios durante los últimos 28 días en cualquier navegador de Chrome.
Si bien es cierto que no sabemos durante cuanto tiempo seguirá siendo así, ya que Google tiene pendiente un juicio antimonopolio por Chrome que dependiendo de la sentencia es posible que en un futuro pueda no obtener esa información de los usuarios (07/07/2025).
Cómo analiza Google la velocidad realmente
Como he comentado antes, Google mide la velocidad teniendo en cuenta un muestreo alto durante los últimos 28 días en los usuarios de Chrome que hayan accedido a tu página.
Dependiendo de su experiencia de usuario y sus resultados, Google entenderá que tu página web es rápida, o lenta, principalmente en base a estos 3 criterios:
- LCP (Largest Contentful Paint): Mide el tiempo que tarde en mostrarse el contenido visible en la pantalla, indicando cuándo carga lo principal que debe ver el usuario cuando accede a la web.
- INP (Interaction to Next Paint): Evalúa lo rápido que una página responde visualmente tras una interacción del usuario (como un click). Se debe tener cuidado con los efectos y animaciones.
- CLS (Cumulative Layout Shift): Se encarga de cuantificar cuánto se mueven los elementos de la web mientras carga (por ejemplo que el texto se mueva de golpe por la carga mientras el usuario lee).
No es lo mismo tener una web con público rural, o en Angola con peor internet, que una misma web con la misma tecnología de programación y todo lo demás cuyo público objetivo suele estar en ordenador con fibra.
El país, dispositivo y conexión de nuestros usuario importa y no hay nada que podamos hacer al respecto.
Dicho esto, podemos saber estas métricas de varias formas:
PageSpeed Insights
Hay un apartado de PageSpeed Insights que es el más relevante y que la gente pasa por alto, y es el primer apartado donde pone «Descubre lo que experimentan los usuarios reales«, solo disponible en la versión web (no la de la Devtools).
Se debe analizar tanto el móvil como el ordenador y pueden ocurrir varias cosas.
Prueba no superada:
En este caso, Google está entendiendo que en base a la experiencia de sus usuarios en los últimos 28 días, estos han tenido una experiencia negativa. En este caso, sí deberíamos esforzarnos en mejorar la velocidad de nuestra web para conseguir mejores resultados en Google.
Prueba superada
En el caso de que tengamos las métricas principales superadas, cualquier esfuerzo que hagamos para mejorar la velocidad, será por la experiencia del usuario, ya que a nivel de Google no mejorará por optimizarlo más.
No hay datos
En este caso, debes esforzarte en otros aspectos antes de revisar la velocidad, pues si bien es posible que tengas la web lenta, esto quiere decir que no se meten suficientes usuarios en tu web al mes para tener la información necesaria.
Por ejemplo, aunque tengamos un 98 de «velocidad», Google ni lo está teniendo en cuenta en esta web porque no entraron los suficientes usuarios en el último mes (algo normal en una web estacional).
Google Search Console
Esta debería ser la mejor forma de medir la velocidad de una web, ya que no es lógico ir página a página o evaluar solo la home para detectar si nuestra web tiene problemas de velocidad según Google.
Para eso tenemos una herramienta gratuita que es nuestra amiga, Google Search Console.
Accediendo al panel donde pone « Core Web Vitals »
Tanto si seleccionamos las URLs pobres, como las que necesitan una mejora, como las rápidas, podremos observar algo rápidamente.
Y es que, además de saber que Google analiza la velocidad de la web en base a los usuarios de Chrome, Google no nos puntúa la página de una en una, sino que nos agrupa la web y los subdirectorios juegan un papel crucial en ello.
Gracias a ellos, Google puede interpretar que son URLs distintas; en este caso, Google en mi Web ha interpretado que los artículos, los artículos en inglés y las páginas troncales son tipos de contenido distinto. Es por ello que se hace un promedio de velocidad.
No obstante, si aparece todo como correcto, de cara a Google no es necesario una mejora de velocidad. Esta es la forma más rápida de comprobarlo (importante revisar tanto móvil como ordenador).
Screaming Frog + API PageSpeed Insights
Tenemos la opción de pasar el análisis de PageSpeed Insights desde el propio Screaming Frog por toda nuestra web sin ir de URL en URL, y sería conectándolo por medio de API a la Search Console.
Si no sabes cómo conseguir el código de la API de PageSpeed Insights puedes conseguir aquí la clave fácilmente.
Se conecta en: configuración de rastreo > contectar APIs > PageSpeed Insights
De este modo, podremos comprobar todas las métricas que nos arroja PageSpeed Insights, incluido el Core Web Vitals.
Herramientas útiles para medir la velocidad de una web
No obstante, no todo es Google y también puede ser que independientemente de cómo perciba Google nuestra web, nuestros usuarios la puedan percibir como rápida o como lenta.
Para analizar la velocidad de una web tenemos que tener en cuenta:
- Los puntos geográficos de nuestro público objetivo: si por ejemplo nuestro público es el mundo hispanohablante, tu web con servidor en Madrid puede ir rápida en España, pero lenta en Colombia.
- Hacer varios análisis y tener un registro para ver la evolución: es posible que analicemos la web en un momento de muchísima demanda por tráfico y usuarios en la web, o a las 3 de la mañana con la web vacía. En ambos casos estaría sesgado, así que debemos tener en cuenta diferentes situaciones, ya que la velocidad dependerá de muchos factores y no podemos tener un valor exacto, sino un promedio. Por otro lado, es conveniente tener un análisis de velocidad guardado antes de mejorar la web de una página para ver la evolución de nuestras implementaciones.
- Analizar con distintas herramientas: es posible que a alguna se le pase algo por alto.
Aquí tenemos formas distintas de comprobarlo, independientemente de Google:
Pingdom
Pingdom Website Speed es una herramienta que te permite analizar la web desde distintos puntos geográficos y ver información sobre el análisis de tu página desde esos puntos.
Devtools
La Consola de Chrome es una herramienta indispensable para el SEO Técnico y para analizar al pormenorizado los efectos de los elementos en una web y entender cómo mejorar su carga.
GTMetrix
Daría más información, pero hay un tutorial sobre GTmetrix extenso y completo en el blog de DinoRANK.
Funciona como Pingdom, pero es incluso más completa. Es importante tener alternativas.
Webpagetest
Si quieres personalización con recurrencia y oportunidad de cuenta gratuita con informes periódicos, webpagetest es una muy buena opción.
Trucos rápidos para mejorar el WPO
Versión HTTP
La versión de HTTP depende de tu servidor, puedes preguntarle a tu hosting, porque como mínimo deberías utilizar el protocolo http/2.
Compresión
Cómo comprobar el tipo de compresión de tu web:
- Para cualquier tipo de compresión GiftOfSpeed
- KeyCDN para Brotli
- Puedes usar la Consola de Chrome para comprobarlo sin herramientas externas
Si no tienes ningún tipo de compresión siempre puedes preguntarme por LinkedIn.
Minificado
Hay múltiples plugins y herramientas que te permiten minificar tu código.
Minificar el código significa quitarle los espacios, las indentaciones y caracteres innecesarios con el fin de que las máquinas sigan leyéndolo igual, aunque los humanos lo entiendan peor.
Con esto lo que se consigue es que los archivos de código (HTML, CSS, JS) pesen menos con el mismo resultado.
Tamaño de archivos
Las imágenes y los vídeos deben tener (pesar) un tamaño óptimo en relación calidad/peso.
Existen herramientas online muy útiles como tinypng.com que además son gratuitas y te pueden ayudar en pocos clicks a bajar el peso sin perder calidad.
Nota de Dean: ¡Me consta! Esa misma web, tinypng.com, es la que yo mismo uso para reducir el peso de muchas de las imágenes que forman parte de los artículos de este blog, lector. Una herramienta básica para bloggers o webmasters preocupados por el peso de las fotos 🙂
No obstante, también te recomiendo compressor.io o plugins automáticos como webp express.
En cuanto a los vídeos, nada como el Software gratuito Handbrake, mano de santo.
Trucos más avanzados
Y dejo por aquí otros trucos rápidos pero que necesitan de un poquito más de conocimiento técnico para su implementación.
CDN (Content Delivery Network)
Un CDN (Content Delivery Network) es una red distribuida de servidores que se utiliza para entregar contenido web al usuario de forma más rápida, eficiente y cercana geográficamente.
El CDN no siempre es una medida eficaz, a veces puede ser contraproducente.
Depende de la carga que soporte tu servidor habitual, del público objetivo, del CDN y del propio plan que elijas dentro del CDN. Incluso de cómo está implementado.
Normalmente recomiendo Cloudflare pero en España está teniendo muchos problemas debido a la polémica con la liga de fútbol. Por lo que mientras se resuelve te puedo recomendar Fastly y si eres menos avanzado BunnyCDN.
Por no dejar aquí ningún enlace de afiliados, lo que dejo es un cupón de descuento que solo te beneficia a ti:
#SAASMASTER
Importante es que compruebes los POP que tiene el CDN por si tienen puntos geográficos cerca de tu región. Esto lo puedes comprobar en CDNPlanet.
Precargas y Cargas diferidas
El orden del código importa tanto como el código en sí mismo.
Aunque hay que tener cuidado al alterar el orden del JavaScript (IMPORTANTÍSIMO si usas plugins sin conocer el tema en profundidad) porque te puedes cargar funcionalidades.
Podemos utilizar atributos como FetchPriority que WordPress los tiene por defecto pero que siempre se pueden optimizar más.
Podemos poner a nuestro favor distintas precargas como el preload, el preconnect o el prefetch.
Podemos utilizar cargas diferidas como el loading lazy, load on click, async o defer.
Teniendo un control del orden en el que cargan nuestros recursos, vamos a poder mejorar la percepción sobre la velocidad de nuestra página, lo que se resume en mejorar la velocidad de la misma.
Caché
El caché es una forma de almacenamiento temporal con el fin de mejorar la velocidad de un sistema.
De hecho, en el propio mundo web existen muchas formas de caché que nos afectan al SEO.
Existen principalmente dos tipos relevantes para SEO:
- El caché del navegador, que evita descargar recursos repetidos (como CSS o JS) desde el servidor,
- El caché del servidor, que guarda versiones ya generadas de las páginas para no tener que procesarlas cada vez.
Ambos se configuran desde el servidor y requieren una estrategia para evitar problemas al hacer cambios en la web.
Además, existen otros tipos como el caché de DNS, CDN o aplicaciones, que también influyen en la velocidad de carga y el comportamiento del sitio.
Puntos clave
No es necesario que te vuelvas un experto de la noche a la mañana, así que comencemos por los puntos clave que se tienen que quedar en tu memoria tras leer este artículo:
- Lo que importa son las métricas de Core Web Vitals (LCP, INP, CLS), no la puntuación de 0 a 100 de la herramienta automatizada de PageSpeed.
- La velocidad de la web no está determinada por la velocidad de la home.
- La velocidad repercute en el SEO de forma directa y de forma indirecta.
- Que la web sea rápida o lenta para Google, no implica que tu percepción haga que tu web sea lenta o rápida.
- Analizando la misma web en momentos distintos te puede arrojar resultados distintos.
Notas del autor
Debo agradecer a Dean Romero la iniciativa que ha tenido para el sector reuniendo a distintos profesionales y haber contado conmigo para este propósito.
Agradezco el espacio y he redactado este post con mucho mimo y cariño para todo aquel que lo haya querido leer.
También con su permiso, me gustaría mencionar que cualquiera que quiera saber todos estos aspectos técnicos en muchísima mayor profundidad, tanto de WPO como otros aspectos del SEO Técnico, siempre será bienvenido al máster de SEO Técnico de Asdrubal.
Pronto más. 😉
19 respuestas
Buenos días,
Buena recopilación de de los puntos más importantes.
Quizás en la parte de los datos de usuarios reales de PageSpeed añadiría la diferencia entre «esta url» y «origen», que el valor que muestra en cada métrica es el percentil 75%, y que al «ampliar vista» te muestra el porcentaje que esta en cada franja. Pero es algo que cualquiera puede ver si juega con el interfaz.
Saludos.
🌐 Mi Web: https://josemimg.com
¡Hola Josemi!
Le comentaré al autor del post que pase por aquí y te de su punto de vista al respecto 🙂
En lo que a mí respecta la optimización WPO técnica a un nivel avanzado se me queda grande porque siempre es algo que prefiero delegar!
Gracias por pasarte
Tienes razón y es algo interesante para añadir en el artículo. Especialmente en caso de tener tráfico suficiente te sirve para saber si dicha URL es la que enturbia las estadísticas.
Realmente luego para las core web vitals (lo puedes ver en search console) Google agrupa conjuntos de URLs para tener en cuenta la velocidad, es raro que las coja de forma individual.
Pero es cierto que te sirve para comprobar si esa URL concreta está bien o es la que perjudica la media.
Gracias por ayudar a hacer el artículo más completo
🌐 Mi Web: https://carlos.sanchezdonate.com/
Hola Dean y Carlos¡
Pues me ha picado la curiosidad y he hecho una prueba en un blog con pingdom y otro test más sencillo.
Luego he cargado las imágenes en GPT para que me explique un poco el jeroglífico de datos 🤣
Por último, lo he compartido en el mismo blog que estaba probando.
Y para acabar he dejado un enlace a este post.
«Si quieres aprender a mejorar la velocidad de tu web, en este post del blog de Dean Romero se explica de manera detallada»
https://diarium.usal.es/a107662/medir-velocidad-web/
Sobre este tema tengo unas cuantas dudas. No voy a chaparos con todas. Probando creo que puedo ir resolviendolas.
Hay que no creo q pueda conocer sin pagar: es si mejoraría la velocidad de carga de mis blogs cambiando el plan que tengo en Raiola.
Me escribieron para cambiar, pero tengo la duda de si merece la pena pagar más.
Si les pregunto a ellos seguro q m dicen q sí … pero una opinión externa estaría bien.
Actualmente ….
Hosting SSD Pro: CPU 80% | RAM 1024 MB
Propuesta …
Hosting SSD Pro 2.0: CPU 150% | RAM 3072 MB
Por cierto, muy bien la herramienta tinypng … en el blog q mencionaba no puedo instalar plugins de compresión, y tengo el espacio limitado, así q voy a darle una compresión a todas las imágenes para mejorar la carga y conseguir espacio.
Salu2
Depende. Y aunque la mejore, quizás es solo para pasar de 2 segundos a 1.9 en la parte de la respuesta del servidor (time to first byte), cuando el problema lo tienes que el navegador tarda 3 segundos en renderizar el html. Puede que tocando 3 o 4 cosas de la configuración obtengas mayores beneficios. O cambiando la plantilla, quitando cosas del diseño. O incluso cambiando de hosting.
🌐 Mi Web: https://josemimg.com
Hola Luis, como te ha comentado Josemi depende.
Del servidor puede ocurrir que no tengas espacio suficiente, o te puede ocurrir que se sature respecto a los procesos internos que tenga que hacer tu web y/o el número de peticiones que tenga que soportar.
¿La web sería la misma que compartes?
Hasta septiembre no tengo acceso a un ordenador, pero puedo mirarlo
🌐 Mi Web: https://carlos.sanchezdonate.com/
Hola Carlos¡
No. La web que comparto está en un servidor de la universidad de Salamanca, Este blog lo uso para notas, apuntes y frikeo de pruebas [posiciona +- bien por autoridad]
Mis weblogs los tengo divididos entre el servidor de raiola, blogger y payhip.
Supongo que terminaré cambiando a lo que m propone raiola … pero esperaré al viernes-ronchas 🙂
Disfruta el verano¡
Gracias Luis, ya tengo curiosidad, si te acuerdas me cuentas que tal la experiencia.
🌐 Mi Web: https://carlos.sanchezdonate.com/
Muchas gracias por el post!
Es algo que quienes no estamos tan avanzados podemos irr mirando y entendiendo más.
En una web de marca que no necesita un tráfico masivo, ves coste beneficio aplicar todas estas técnicas?
O con una optimización básica sería suficiente?
Un saludo!!!
🌐 Mi Web: http://soyhectornunez.com
Una web que no reciba suficiente tráfico como para tener una muestra representativa y aparecer en PageSpeed Insights no será tan tenida en cuenta de cara a los Core Web Vitals.
Tampoco se necesita un tráfico masivo para aparecer; incluso a veces puedes quedarte en el limbo: habiendo periodos en los que sí se recoge muestra representativa suficiente y otros en los que no (las webs y sus estadísticas no son algo estático).
Para verlo más sencillo, lo interesante es “aparecer en verde” en los Core Web Vitals que indica Search Console. No obstante, también hay que comprobar si existen otros fallos más importantes que revisar (rastreo, renderizado, indexación…).
Eso sí, es cierto que cuanto más grande es la web y mayor es la competencia, más repercute la velocidad.
Si tienes una web de marca cuyo tráfico procede principalmente de redes sociales o de búsquedas por tu nombre, optimizar al máximo la velocidad quizá no sea lo que más retorno te aporte (incluso según como se haga te puede salir contraeconómico).
Aun así, siempre debe mantenerse un mínimo para que la web sea, como poco, navegable. Aunque haya poquitos usuarios y sean fieles a tu contenido.
🌐 Mi Web: https://carlos.sanchezdonate.com/
El impacto sería menor en ese caso Hector, de hacer todas estas cosas
De todos modos para dar una respuesta precisa habría que ver con detalle cada caso en particular, por ejemplo, quizás tu web no tenga tráfico pero quizás si aspira a tenerlo por SEO en un futuro (solo especulo), en ese caso tendrá algo más de relevancia hacer WPO
Siempre que quieras ser competitivo trayendo tráfico de buscadores y que tengas competencia el WPO es relevante, pero si el tráfico viene de redes u otros canales o es una tipología de tráfico en definitiva que no viene de buscadores como Google es menos relevante
Muchas gracias 👍🏽😊
🌐 Mi Web: http://soyhectornunez.com
Hola Carlos, hola Dean!
Hay dos temas que me encantan en la actualidad uno de ellos es el seo técnico 😍, aunque reconozco que hay temas que pueden hacerse algo pesados, y otro todo lo relacionado con la IA 🥰. Así que esta vez me anino a comentar.
Este artículo me parece muy acertado, bien explicado y directo 👌. Gracias Carlos!
Creo que algo importante al interpretar Core Web Vitals es entender que los resultados no dependen solo de la web en sí, sino también de la audiencia real: no es lo mismo medir con usuarios que se conectan con fibra y móviles modernos que con conexiones lentas o dispositivos antiguos. Eso explica por qué los informes de Search Console son tan dinámicos y pueden variar cada 28 días incluso sin tocar nada en la web.
Y un apunte más: muchas de las optimizaciones clave (preload de fuentes, minimizar CLS, reducir JS…) pienso que son más propias del trabajo de desarrollo. El rol del SEO debería ser priorizar y traducir los problemas en tareas claras para el equipo de desarrollo, en lugar de obsesionarse con el “100” de PageSpeed. Así se evitan frustraciones y se trabaja de forma más estratégica 😉. Y aquí es cuándo abro un melón… ¿se necesita saber programar para hacer SEO técnico?? Yo soy de las que piensa que no está de más saber al menos algo de programación o al menos entender el código.
He estado unas semanas desconectada para recargar pilas, pero mañana ya vuelvo con la batería llena 💪 y me encantaría retomar mi blog. Tal vez lo haga con algún artículo hablando sobre las Core Web Vitals, que siempre dan juego y me apetece repasar 😊.
¡Un saludo!
🌐 Mi Web: http://Sirimiridigital.com
Hola Amaya! Te copio y pego la respuesta de Carlos, que ahora anda de vacaciones 😁
Muy buenas Amaya!
Lo primero, muchas gracias por tu comentario. Estoy muy de acuerdo con lo que has comentado, en CWV no todo depende de lo que nosotros hacemos, también hay una parte importante que tiene que ver con el dispositivo y la conexión del usuario, pero está claro que si no optimizamos la velocidad de una web, da igual cómo sea el usuario, siempre va a ser lenta, por lo que es una ventaja importante respecto a la competencia, tener una buenas métricas en CWV.
En cuanto a las tareas que mencionas de los desarrolladores, es así, pero el problema que tenemos con el SEO, es que son cosas que a los desarrolladores muchas veces les dan exactamente igual. Su función es que la web sea funcional, valga la redundancia, no que esté bien optimizada para SEO. Por lo que muchas veces nos encontramos, en nuestros proyectos, que si no aplicamos estas cosas nosotros mismos nadie les va a dar importancia.
En cuanto al código, ligado a lo anterior que he comentado de los desarrolladores, si no sabemos cómo hacer estas cosas o, por lo menos, como identificarlas, tendremos una pérdida de oportunidad en nuestras webs respecto al SEO técnico. Por eso, como comentas, es muy importante tener unas bases de conocimiento de código para SEO técnico.
¡Un saludo!
Da gusto ver tu pasión por el SEO Amaya
Mantenla y haz mucho contenido, lo demás irá ocurriendo solo 😉
Hacia falta un artículo como este.
Poco se habla sobre las trampas del Page Speed Test. El propio nombre es engañoso, y a menudo confunde a los usuarios. Cuando explico esto a mis clientes de optimización, lo entienden mucho mejor y podemos trabajar juntos en la optimización real, en lugar de solo centrarnos en los resultados de un test de laboratorio.
🌐 Mi Web: https://thinkfocus.es
Muchísimas gracias por el feedback Raul
🌐 Mi Web: https://carlos.sanchezdonate.com/
Excelente Post Carlos,
Esto es algo complicado de enseñar sobre todo los C levels, los cuales no diferencian que el puntaje del 0 al 100 en PSI son datos de laboratorio y que no muestran realmente la realidad de la web, que es por URLs y no es el home el que muestra toda la perspectiva.
Además, esta tipo de optimizaciones de las CWV se vuelven una pesadilla cuando trabajas con marcas que emplean servidores seguros con múltiples reglas de ciberseguridad con bloqueos de CSP, WAF, proxys reversos y NGFW que hacen que el servidor tarde una vida en responder y los de TI no ayudan a solucionar.
Totalmente, al final la seguridad siempre rompe de una forma u otra confort.
Yo siempre pongo el ejemplo de que en una casa puedes poner un foso con cocodrilos y una trampa de pinchos. Entrarán menos ladrones, pero te hará más incómoda la entrada.
Claro ahí está el evaluar como de necesario es. Hay marcas potentes que de verdad necesitan grandes sistemas de seguridad. A partir de ahí, teniendo claro cuales son las necesidades del clientes, está en nuestro trabajo el cómo hacer una web más rápida sin alterar las funciones de la web.
A mi me gusta bastante porque a diferencia de como suele creer la gente que es poner un plugin de optimización y a volar, es un trabajo bastante creativo que para hacerlo bien requiere de soluciones personalizadas.
🌐 Mi Web: https://carlos.sanchezdonate.com/