Todo el mundo dice que «la web tiene que cargar rápido» y casi nadie explica qué significa eso en la práctica ni cuánto pesa de verdad en si un paciente se queda. Nosotros lo medimos en nuestra propia web el 23 de agosto: 71 puntos en PageSpeed móvil. Después de quitar lo que sobraba, 99. Este artículo cuenta qué se cambió, por qué eso funcionó y no otra cosa, y qué puedes mirar en la tuya aunque no sepas programar.
Dos motivos, y ninguno tiene que ver con «quedar bien» con Google: uno es de posicionamiento y el otro es que el paciente se va antes de leerte.
Desde 2018, Google incluye la velocidad de la página como una de las señales que usa para ordenar los resultados de búsqueda en móvil. No es la única, y no gana quien más rápido carga sin más; pero entre dos webs igual de relevantes, la que tarda menos parte con ventaja. Es la misma lógica que ya contamos en qué es el SEO y por qué es clave para que tu clínica consiga pacientes: el SEO técnico no es una capa extra, es una condición para que lo demás funcione.
Casi todas las búsquedas de «dentista cerca de mí» o «fisioterapeuta en [tu ciudad]» ocurren en el móvil, muchas veces con poca cobertura o mientras se hace otra cosa. Si la página tarda en aparecer, esa persona no piensa «espero un poco más»: vuelve atrás y abre el siguiente resultado, que suele ser tu competencia. No hace falta que la web esté mal diseñada para perder a ese paciente; basta con que tarde.
Puedes tener el UX mejor pensado del sector, pero si la pantalla tarda en pintarse, nadie lo llega a ver. La velocidad no compite con el diseño: es lo que decide si el diseño tiene ocasión de hacer su trabajo. De eso hablamos con más detalle en qué errores hacen que los usuarios abandonen tu web.
No es una cifra que nos hayan contado. Es la que medimos en nuestra propia web, con la misma herramienta que puedes usar tú.
El 23 de agosto medimos PageSpeed Insights sobre esta web tal y como se servía entonces: 71 puntos en rendimiento móvil. No era un desastre —seguía siendo una web que funcionaba, que se veía bien y que cargaba en un tiempo razonable—, pero estaba lejos de lo que la propia herramienta considera «bueno» (90 o más).
Después de los cambios que cuenta el siguiente apartado, la misma medición dio 99 en rendimiento móvil, 96 en accesibilidad, 100 en prácticas recomendadas y 100 en SEO. Ese compromiso —90 o más en PageSpeed móvil— es hoy lo que publicamos en desarrollo web y en SEO técnico, y se cumple con margen.
Ninguno de estos cuatro cambios fue «comprimir imágenes» ni «minificar código». Fueron dejar de pedirle cosas a servidores ajenos antes de poder pintar la página.
Las páginas descargaban 31 KB de CSS y 77 KB de tipografía de Font Awesome para pintar un único icono: la lupa del buscador. Ahora es un SVG en línea de unas pocas decenas de bytes, sin ninguna petición a otro servidor.
Pedir Poppins a Google Fonts añadía dos orígenes externos y una hoja de estilos que bloqueaba el pintado hasta que llegaba. Ahora los cuatro pesos que se usan —31,5 KB en total— viven en estilo/fuentes/, en el mismo servidor que el resto de la web.
La librería de animaciones al hacer scroll se pedía a unpkg.com. Un origen externo menos: ahora se sirve desde el propio dominio y se carga con defer, para que no compita con lo que el usuario necesita ver primero.
De las imágenes del sitio, la mayoría llevan loading="lazy": no se descargan hasta que el usuario está a punto de llegar a ellas. El logo y lo primero que se ve al abrir la página son la excepción a propósito: eso sí tiene que estar ahí desde el primer segundo.
Es la más contraintuitiva de las cuatro, y la que más se pasa por alto cuando alguien intenta acelerar una web a base de comprimir imágenes.
Los cuatro cambios anteriores tienen algo en común: ninguno reduce mucho el peso total de la página. Lo que reducen es el número de servidores distintos a los que el navegador tiene que conectarse antes de poder enseñar algo.
Es la diferencia entre pedirle un archivo a un servidor con el que ya estás hablando y pedírselo a uno nuevo: el segundo empieza de cero. Google Fonts, Font Awesome y la librería de animaciones eran tres «empezar de cero» distintos, en serie, antes del primer pintado. Autoalojar esos tres archivos no los hizo más ligeros: hizo que el navegador dejara de tener que presentarse tres veces más.
Y una nota sobre medir, por si algún día te toca comprobar tu propia web: una puntuación suelta no sirve para comparar. PageSpeed simula una CPU lenta y una red móvil, y entre dos ejecuciones seguidas puede haber variaciones de ±10 puntos con toda normalidad. Si un día parece que ha bajado, mide tres veces y quédate con la del medio antes de tocar nada.
No hace falta entender de código para hacer las preguntas correctas. Estas son las que nosotros nos hacemos con cada web que entregamos.
Y si alguien te añade un widget nuevo dentro de un mes —un chat, un calendario de reservas, un píxel de campaña—, vuelve a medir. El compromiso de 90 o más que publicamos se mide sobre la web tal y como se entrega: lo que se añada después, con buena intención, también tiene coste.
La velocidad de carga no se arregla comprimiendo lo que ya tienes: se arregla dejando de pedirle cosas a servidores que no son el tuyo. Es lo que hicimos en nuestra propia web —de 71 a 99— y es lo primero que revisamos en cualquier web que llega a nuestras manos.
Cuéntanos la URL de tu web y te decimos, sin compromiso, dónde está perdiendo velocidad.