Analizamos los cuellos de botella típicos y el procedimiento para eliminarlos tomando como ejemplo un portal con 200.000 visitas al día.
En una página pequeña es fácil pasar por alto un script innecesario. En un portal grande se carga una y otra vez, ocupa tiempo del navegador y puede retrasar el menú, la búsqueda o el envío de formularios.
Al mismo tiempo, la misma queja “el sitio es lento” puede significar diferentes problemas. Para un visitante, un artículo tarda mucho en aparecer, para otro, la búsqueda se congela, para un tercero, la página no se abre durante las horas pico. Comprar un servidor más caro sólo ayudará a algunos de ellos.
Para el análisis usaremos un portal hipotético con 200.000 visitas al día. Los ejemplos técnicos proceden de nuestras mejoras en otra web: cambios en la presentación de artículos, incorporación de páginas relacionadas y eliminación de módulos innecesarios. No se trata de un informe de aceleración de un portal real con ese volumen de visitas.
Primero debes entender dónde se pierde el tiempo.
Antes de intervenir, dividiríamos la comprobación en tres partes:
- Respuesta del servidor. Cuánto tiempo pasa antes de que se comience a recibir la página.
- Aparición del contenido principal. Cuándo ve el visitante el artículo, la imagen u otro bloque principal.
- Reacción a las acciones. Qué tan rápido se abren los menús, las búsquedas y los formularios.
Medir sólo la página de inicio no es suficiente. El portal puede tener artículos rápidos y búsqueda lenta, y los usuarios registrados pueden tener tiempos de carga diferentes a los usuarios invitados.
Las visitas diarias no determinan por sí solas la carga. Importan las páginas vistas, las peticiones al servidor y su distribución en el tiempo. Un portal que recibe la mitad de sus visitas en una hora tras una noticia importante es distinto de una web con tráfico uniforme.
1. La página carga imágenes demasiado pesadas.
La portada de un artículo puede mostrarse con varios cientos de píxeles de ancho y cargarse en su tamaño original. Si hay varias imágenes de este tipo, el visitante descarga datos que no proporcionan una mejora notable en la calidad de su pantalla.
Debe verificar el tamaño de los archivos y cuándo el navegador comienza a descargarlos. La portada debe aparecer a tiempo y las imágenes que se encuentran en la parte inferior de la página se pueden cargar a medida que se acerca a ellas. No debes retrasar indiscriminadamente la carga de la imagen principal: esto puede empeorar el tiempo de aparición del contenido principal. Se pueden encontrar más detalles sobre esta dependencia en la guía de optimización de LCP.
En nuestra historia de trabajo, primero se cambió el diseño de un artículo y luego se amplió a 300 publicaciones. Este es un ejemplo de por qué es importante una plantilla común: una decisión que se toma allí se repite a lo largo de cientos de páginas. Pero la actualización del diseño en sí no prueba la aceleración.
Coste del problema. Supongamos que el navegador descarga 1 MB adicional de imágenes en cada una de las 200.000 visitas. Son unos 200 GB extra al día, o 6 TB en 30 días. Es un cálculo hipotético: el volumen real depende de las páginas vistas, la caché del navegador y las descargas repetidas. La factura depende del plan de alojamiento o CDN.
Qué corregir. Preparar los tamaños adecuados de imagen, seleccionar la versión según la pantalla y ajustar el orden de carga. El presupuesto debe incluir la comprobación de plantillas y de la calidad visual después del tratamiento, además de la compresión de archivos.
2. El navegador está ocupado con scripts que la página no necesita.
El artículo ya está visible, pero el menú se abre con retraso. La búsqueda no responde inmediatamente y el desplazamiento se vuelve desigual. En este caso, el problema puede estar en el código que se ejecuta en el dispositivo del visitante.
El motivo son los widgets, bloques de anuncios, controladores de eventos y módulos conectados en todas las páginas, independientemente de la necesidad. Los diagnósticos deberían mostrar qué código está retrasando una acción específica. Para evaluar la capacidad de respuesta se utiliza la métrica INP, descrita en la guía de optimización de interacciones.
En una de nuestras versiones desactivamos un módulo público. Retiramos tanto el bloque como sus estilos, scripts y ruta pública de programación. Ocultar el bloque únicamente mediante CSS habría mantenido parte del trabajo innecesario.
En el portal, se debe hacer la misma pregunta para cada componente: ¿se necesita un reproductor de video en un artículo de texto? ¿Se debe cargar el widget antes de que el usuario lo abra? ¿Se utiliza esta biblioteca?
Coste del problema. El visitante espera a que la interfaz responda aunque la página ya esté cargada. Un servidor más potente no elimina el código pesado que se ejecuta en su navegador.
Qué corregir. Eliminar componentes sin uso, cargar el código solo donde hace falta y aplazar tareas secundarias. Después hay que comprobar las funciones: el script eliminado podía servir también a un formulario o a la analítica.
3. El servidor repite los cálculos, cuyo resultado permanece casi sin cambios.
La página del portal puede contener colecciones de materiales, enlaces sobre el tema, calificaciones y contadores. Si cada vez que abre un artículo, el sistema vuelve a buscar publicaciones relacionadas y realiza muchas consultas a la base de datos, la carga crece junto con las vistas.
Debe verificar el tiempo de ejecución de consultas y funciones específicas. La cantidad de complementos instalados por sí sola no explica la latencia: un componente puede hacer más trabajo que varios otros juntos.
En nuestro proyecto, el bloque de páginas relacionadas apareció en 273 publicaciones y contenía 539 enlaces. Preparamos las relaciones de antemano y la web consultaba ese mapa al abrir la página. No añadimos una selección por palabras clave durante cada petición ni una nueva dependencia de JavaScript.
Para el portal, esto se aplica a las colecciones que cambian al editar el material. Las recomendaciones personalizadas requieren un enfoque diferente.
Coste del problema. Los cálculos repetidos consumen recursos del procesador y la base de datos. Cuando aumenta la carga, las peticiones pueden acumularse y crecer los gastos de infraestructura.
Qué corregir. Localizar operaciones costosas, eliminar consultas repetidas y preparar de antemano los resultados que no cambian. El coste depende de si basta con modificar un bloque o hay que rediseñar la búsqueda y los datos.
4. El caché no se utiliza donde podría ayudar.
Si mil lectores abren el mismo artículo público, el servidor no siempre necesita crear la misma página mil veces.
El caché le permite reutilizar el resultado preparado. Pero primero debe verificar qué solicitudes realmente obtienen una copia lista y cuáles ejecutan la aplicación cada vez. La configuración de caché y base de datos se incluye en Recomendaciones de rendimiento de WordPress.
También hay que comprobar qué ocurre al publicar una noticia o vaciar la caché. Que las páginas ya almacenadas respondan rápido no demuestra cómo soportará el sistema las visitas simultáneas a contenido aún no preparado.
Las páginas personales requieren reglas separadas. Una caché compartida no debería proporcionarle a una persona los datos de otro usuario.
Coste del problema. El servidor repite el trabajo para peticiones idénticas. Una configuración que conserve demasiado tiempo el resultado también puede mostrar contenido antiguo o un estado incorrecto de la página.
Qué corregir. Definir qué se puede almacenar en caché, durante cuánto tiempo y cuándo se actualiza. Comprobar el acceso de visitantes y usuarios con sesión iniciada, la publicación de cambios y el funcionamiento después de vaciar la caché. Instalar un plugin sin estas pruebas no completa el trabajo.
5. El servidor o uno de los servicios intermedios falla
A veces una aplicación realmente no tiene suficientes recursos. Pero entre el visitante y el sitio puede haber una CDN, protección contra ataques y otros servicios. Sus errores deben distinguirse de los problemas del servidor principal.
En nuestros registros hay un caso en el que las peticiones a un archivo CSS recibían temporalmente un error 502 en un servicio de protección intermedio. La comprobación posterior fue satisfactoria. No demuestra una lentitud crónica de la web, pero recuerda que hay que revisar también los servicios intermedios.
También conviene descartar cargas ajenas al funcionamiento previsto. Encontramos archivos maliciosos en el proyecto original, pero no medimos su efecto en la velocidad y no sería correcto atribuirles la lentitud.
Coste del problema. En horas punta aumentan las demoras o aparecen errores. El propietario puede pagar por más recursos aunque la causa esté en un servicio externo, una tarea en segundo plano o una petición concreta.
Qué corregir. Relacionar los errores con los momentos de carga y comprobar procesador, memoria, disco y colas. Después se determina si basta con ajustar la configuración, corregir código o ampliar recursos. Durante una incidencia activa puede estar justificado ampliar recursos temporalmente antes de acabar la investigación.
Cómo estimar el coste económico de una web lenta
Sin análisis, es imposible decir que cada segundo extra vale un cierto porcentaje de los ingresos. Para un portal publicitario, puede comenzar con la cantidad de visitas y los ingresos reales por cada mil visitas.
Ejemplo hipotético, expresado en rublos:
- el portal recibe 200.000 visitas diarias;
- la profundidad de navegación promedio disminuyó en 0,2 páginas;
- El ingreso medio es de 100 rublos por cada mil páginas vistas.
La diferencia sería de 40.000 páginas vistas al día, o 1,2 millones en 30 días. Con ese ingreso, equivaldría a 120.000 rublos al mes.
Este es un escenario aritmético, no una estimación de las pérdidas de nuestro proyecto. Para atribuir la disminución de la profundidad a la velocidad, es necesario comprobar otros motivos: fuentes de tráfico, dispositivos, contenido y estacionalidad. Y los ingresos por cada mil páginas vistas no pueden sustituirse por la tasa por cada mil impresiones publicitarias.
¿En qué orden debería solucionar los problemas?
Es mejor comenzar con mediciones en varios tipos de páginas: página principal, artículo, categoría, búsqueda y cuenta personal, si tiene una. Los dispositivos móviles y de escritorio deben verse por separado. Una prueba de laboratorio ayuda a encontrar la causa y los datos de visitas reales muestran el alcance del problema.
El orden adicional depende del resultado:
- Errores e indisponibilidad. Primero, restablezca la operación y elimine las amenazas confirmadas.
- Respuesta lenta del servidor. Comprenda consultas, dependencias externas, caché y limitaciones de recursos.
- El contenido tarda en aparecer. Revisar imágenes, estilos y orden de carga.
- Retrasos en la acción. Encuentre código que interfiera con los menús, la búsqueda y los formularios.
- Vuelva a comprobar. Compare el resultado en condiciones comparables y asegúrese de que se conserven las funciones.
Esta no es una lista de trabajos que deban completarse en su totalidad en ningún sitio. Si el retraso se debe a una solicitud externa, no tiene sentido comenzar a procesar todas las imágenes.
Qué debe incluir el presupuesto de optimización de velocidad
La frase “aceleraremos el sitio” es demasiado vaga para acordar un presupuesto. Antes de empezar a trabajar, conviene obtener respuestas a cuatro preguntas:
- ¿Dónde se detectó el retraso y cómo se confirmó?
- ¿Qué cambios se proponen?
- ¿Con qué indicadores se comprobarán los resultados?
- ¿Qué está incluido en el precio: diagnóstico, desarrollo, pruebas, implementación y reversión?
Sin estos datos, es imposible dar un costo universal para corregir cada una de las cinco causas. Ajustar el tamaño de las imágenes en una plantilla ya preparada y reelaborar la búsqueda en un portal grande pueden ser tareas de escalas completamente diferentes.
Para un portal con 200.000 visitas al día, el primer resultado útil del diagnóstico debe concretar qué páginas y operaciones tardan, cuánto contribuyen a la demora y en qué orden se propone corregirlas, con una estimación por etapa. Así se puede pagar el trabajo por fases y comprobar el efecto antes de invertir en la siguiente.