Respuesta breve
Casi toda queja sobre velocidad se reduce a una métrica, a una decisión de construcción y a una línea del catálogo. Aquí está esa correspondencia, desde la pantalla en blanco hasta el botón que se movió bajo el dedo.
El LCP no puntúa la página: cronometra un elemento
Conviene empezar por lo que el LCP no es, porque casi todo el mundo lo lee mal: no es una nota de la página, ni el tiempo total de carga, ni el número de peticiones que hace el navegador. El Largest Contentful Paint cronometra un único instante contado desde que arranca la navegación, el momento en que termina de dibujarse el elemento más grande que cabe en la primera pantalla, sea una imagen o un bloque de texto. Ese elemento lo eligió alguien al maquetar. La ficha Aceleración del sitio web y Core Web Vitals por debajo del umbral de Google pone la meta en números: LCP hasta 2,5 s.
Cuatro decisiones de maquetación bastan para explicar un LCP malo, y las cuatro se detectan mirando el diseño en lugar del código. Una fotografía a sangre exportada en resolución de escritorio y servida a un teléfono. Un carrusel que descarga todas sus diapositivas para enseñar la primera. Un titular que no pinta una sola letra hasta que llega la tipografía web. Una hoja de estilos en la cabecera que retiene el renderizado hasta el último byte. Ninguna es una avería: se tomaron a propósito, por motivos que entonces parecían buenos, y ninguna hace saltar una alarma el día que se toma.
El catálogo le pone nombre y precio a esa pasada: Green PageSpeed y Core Web Vitals, categoría Optimización, dificultad Con experiencia, $200 – $600 u 8 000 – 25 000 ₽ en 5-12 horas. Que resulte la más barata de las tres métricas no es casualidad, sino consecuencia de que la lista de intervenciones se cierra: redimensionar y recomprimir la imagen principal, servirla en un formato moderno, precargarla, quitarle a la tipografía el poder de bloquear el primer pintado y apartar del camino crítico lo que retiene el renderizado. Son cinco tareas con final visible, y el resultado se comprueba repitiendo la misma medición que se tomó antes de empezar. Cotizar en horas y no en días solo es posible cuando la lista se puede escribir entera de antemano.
No todo el LCP vive en el navegador. Si la primera respuesta del servidor tarda un segundo en salir, esa espera ya está dentro de su cifra antes de que exista un solo píxel que comprimir, y comprimir imágenes no recupera ese tiempo. Lo que hay que tocar entonces es cómo se fabrica la página, no qué se envía, y eso ya no cabe en una pasada de optimización. Por eso la otra ficha del catálogo antepone una etapa de medición: 1 día de diagnóstico + 1 a 3 días de implementación.
El INP empieza a contar cuando usted toca la pantalla
Aquí está la trampa que descoloca a casi todo el mundo: una página puede pintar su primera pantalla holgadamente por debajo de los 2,5 s de LCP y seguir siendo insoportable en cada botón. Dibujar y responder dependen de cosas distintas, y el Interaction to Next Paint solo mide la segunda, es decir cuánto tarda la pantalla en cambiar visiblemente después de que usted toca, hace clic o pulsa una tecla. A diferencia del LCP no mira el primer segundo sino la visita entera, y se queda con las interacciones que salieron mal en lugar de con las que salieron bien. El umbral que fija el catálogo es INP hasta 200 ms.
Lo que el usuario está esperando, sin saberlo, es su turno en una cola. Detrás de un INP malo casi siempre hay una sola decisión repetida muchas veces: cuánto JavaScript se deja ocupar el hilo principal mientras alguien intenta usar la página. Un framework que rehidrata una interfaz ya dibujada, una analítica que recalcula en cada desplazamiento, un widget de chat, un gestor de consentimiento, un gestor de etiquetas que arrastra otras cuantas, una grabadora de sesiones, un script de experimentos decidiendo qué variante le toca. Ninguno se aprobó como un problema y ninguno llegó el mismo mes que los demás; el efecto conjunto es que la pulsación entra en la cola la última.
El INP sale más caro que el LCP, y la razón de fondo no es técnica. No hay un archivo que optimizar ni nada que comprimir: el trabajo consiste en borrar, aplazar y reordenar código que alguien añadió a propósito, y cada una de esas líneas tiene dueño en marketing, dispuesto a preguntar por qué su herramienta dejó de reportar. Medir y reordenar se cuenta en horas. Decidir qué scripts tienen derecho a arrancar antes de la primera interacción se cuenta en reuniones, y por eso la ficha se agenda en días.
Por eso la ficha de aceleración no se vende con una horquilla de horas sino con un calendario: 1 día de diagnóstico + 1 a 3 días de implementación, por $200 – $800 o 10 000 – 40 000 ₽. Las dos formas prometen cosas distintas. Una horquilla de horas dice cuánto trabajo hay; un calendario dice en qué orden se hace, y reconoce que el primer día entrega conocimiento en lugar de velocidad. El tamaño de los días siguientes lo decide lo que aparezca en el primero.
El CLS no es un retraso: es un movimiento
El único de los tres que no se expresa en unidades de tiempo es el CLS, y por eso su umbral, CLS hasta 0,1, no dice gran cosa a primera vista. Lo que suma esa cifra son desplazamientos: cuánto se mueven por su cuenta los elementos que el usuario no ha tocado. De ahí que registre un fracaso posterior al éxito aparente, cuando la página ya parece cargada, el lector ya ha empezado a leer y entonces llega un bloque con retraso y le empuja el párrafo hacia abajo. El catálogo lo describe con la misma palabra que usan los clientes: el sitio salta mientras carga.
Todas las causas son la misma costumbre repetida, la de no reservar sitio para lo que va a llegar más tarde. Una etiqueta de imagen sin ancho ni alto deja al navegador sin saber qué hueco dejar. Un banner inyectado por script aparece encima del contenido y lo empuja hacia abajo. Un aviso de cookies que separa la página en lugar de flotar sobre ella hace lo mismo con la portada entera. Una tipografía web más ancha que la de reserva reescribe cada línea en el instante en que carga, y los bloques diferidos se despliegan al llegar. No comparten código: comparten una obligación olvidada, la de declarar el tamaño por adelantado.
Corregirlo sale barato en horas —atributos de tamaño y contenedores reservados, nada de arquitectura— y ahí está justamente la trampa, porque también es lo más fácil de deshacer sin querer. La etiqueta de marketing que alguien añada el trimestre que viene volverá a inyectar un bloque sobre el contenido, y no fallará nada ni se pondrá nada en rojo en el registro de compilación. Una corrección que vive en las plantillas sobrevive a la siguiente campaña. Una pasada puntual sobre las páginas de hoy no tiene ninguna garantía de sobrevivir a las de mañana.
Ningún cliente le va a decir que tiene un problema de CLS, y ni siquiera le dirá que se le movió la maquetación. Le dirá que pulsó donde no quería, que el sitio le suscribió a algo sin permiso o que parece hecho a la ligera. La traducción es la misma en los tres casos: en un teléfono el pulgar ya va en movimiento mientras la página termina de montarse, así que un botón que se desplaza acaba en un toque equivocado. Y un toque equivocado en la pantalla de pago tiene otro nombre, pedido abandonado.
Una pantalla, dos informes: laboratorio y campo
Dentro de PageSpeed Insights conviven dos informes que no se parecen en nada, y buena parte de los malentendidos de este sector nacen de citarlos como si fueran uno. El primero es una ejecución sintética: dispositivo simulado, conexión estrangulada, lanzamiento bajo demanda y resultado inmediato. El segundo son datos de campo, recogidos de los navegadores de quienes visitaron de verdad y agregados a lo largo de una ventana móvil. Casi siempre se comparte el primero, porque está listo al momento y porque reacciona de forma visible en cuanto se comprime una imagen.
La ficha Green PageSpeed y Core Web Vitals elige documento y lo dice: el sitio pasa de la zona roja a la zona verde según Core Web Vitals móviles, y el cliente ve los números antes y después. Al comprador le interesan las dos mitades por separado. La primera fija el perfil móvil, que es el exigente. La segunda fija dos mediciones en lugar de una, que es lo que permite comprobar el trabajo en vez de creérselo.
El calendario es donde esto se complica. La ejecución sintética responde el día del despliegue; los datos de campo no pueden hacerlo, porque agregan visitas que ya ocurrieron y solo se mueven a medida que las antiguas van saliendo de la ventana. Durante ese intervalo un sitio arreglado de verdad sigue enseñando las cifras de antes. Quien le prometa el campo en verde el día de la subida está describiendo el laboratorio con el nombre del campo.
Todo esto se resuelve en una línea del presupuesto, no en el código. Antes de tocar nada conviene tomar las dos lecturas y dejar escrito cuál de ellas da el trabajo por bueno, porque cada una trae su propio calendario de verificación: la nota sintética se comprueba el mismo día, y los datos de campo esperan a que la ventana se renueve. Un informe que llega semanas después no es una excusa, es la única forma de leer el campo. Discutirlo más tarde, con el trabajo ya hecho, es lo que sale caro.
La única ficha con el precio partido en dos
Aceleración del sitio web y Core Web Vitals por debajo del umbral de Google se puede contratar de dos maneras distintas, y el catálogo las escribe por separado. Con implementación incluida cuesta 10 000 – 40 000 ₽. Como solo auditoría sin correcciones, 8 000–15 000 ₽. En dólares la ficha completa va de $200 – $800, y el plazo aparece en etapas en lugar de en horas: 1 día de diagnóstico + 1 a 3 días de implementación.
Nadie puede poner precio a una reparación cuyo alcance todavía no conoce, y ese es todo el motivo del desglose. Medir sí se puede presupuestar: se rastrea, se le atribuye una causa a cada milisegundo lento y se acaba cuando no queda ninguno suelto. Reparar depende por completo de lo que aparezca en esa lista, porque una imagen principal demasiado pesada se resuelve en una pasada corta sobre los recursos, mientras que una página generada contra base de datos en cada petición es un proyecto de otra escala. Juntar las dos mitades en una cifra única obliga a cubrirse por el peor caso, y quien paga acaba financiando esa reserva.
Compare dos de las cifras de esa ficha, a modo de ejemplo de razonamiento y no de tarifa: 15 000 ₽ y 10 000 ₽. La primera es el techo de la auditoría suelta; la segunda, el suelo del paquete que además implementa. Investigar sin arreglar puede entonces salir más caro que investigar y arreglar, lo cual solo tiene sentido si la auditoría se cotiza por el esfuerzo de entender y no por el tamaño del parche. Y es exactamente así: hay sitios cuya causa se localiza en una tarde y sitios que se resisten durante días.
Se suele leer la auditoría suelta como la opción barata, y no lo es: es la opción para quien ya tiene el equipo montado. Una empresa con programadores en plantilla no necesita más manos, necesita saber en qué orden atacar, y esa lista priorizada de causas entra en el sprint siguiente sin contratar a nadie. Pagarla a tarifa de implementación sería pagar dos veces por lo mismo, así que el catálogo la vende por su cuenta: solo auditoría sin correcciones, 8 000–15 000 ₽. Y si al final la ejecución se encarga fuera, el documento viaja con el encargo como pliego.
Dos fichas de velocidad: la frontera está en las unidades
Dos fichas distintas prometen lo mismo por escrito, así que el nombre no le va a servir para elegir. Green PageSpeed y Core Web Vitals vive en la categoría Optimización con dificultad Con experiencia, cuesta $200 – $600 u 8 000 – 25 000 ₽ y se entrega en 5-12 horas. Aceleración del sitio web y Core Web Vitals por debajo del umbral de Google vive en Velocidad, repite dificultad Con experiencia y cuesta $200 – $800 o 10 000 – 40 000 ₽, pero su plazo no está escrito en horas: 1 día de diagnóstico + 1 a 3 días de implementación.
Cuando alguien le cotiza en horas le está diciendo, sin decirlo, que ya sabe qué hay que hacer y solo está midiendo cuánto tardará. Un calendario dice algo distinto: que el orden importa más que el total, y que el primer bloque de tiempo existe para decidir el contenido de los siguientes. De ahí que el rango del final, de 1 a 3 días, sea incertidumbre puesta por escrito y no un colchón disimulado. Las dos formas son honestas; lo que no funciona es exigir un número cerrado antes de que exista la lista.
Hay dos frases típicas de cliente y cada una lleva a una ficha distinta. La primera suena así: «la imagen de portada se sirve en resolución de escritorio y hay cuatro scripts del gestor de etiquetas arrancando antes de la primera interacción». Quien puede decir eso ya tiene hecho el diagnóstico y lo que compra es ejecución, con la ficha cotizada en horas. La segunda suena así: «tenemos la nota en rojo y el de campañas se queja». Ahí todavía no hay causa, solo síntoma, y contratar implementación en ese punto equivale a pagar para que alguien adivine con su dinero.
Queda un dato compartido que vale más que cualquiera de las dos horquillas: ambas están marcadas Con experiencia. Las dos editan el camino de renderizado de una página que ahora mismo genera ingresos, y ahí un error no es cosmético, lo ven todos los visitantes a la vez. Los precios, en cambio, no distinguen nada por abajo, porque las dos arrancan en $200. La dificultad le dice a quién puede encargarle el trabajo; la horquilla solo le dice cuánto trabajo podría llegar a haber.
La adaptación móvil arregla el uso, no la velocidad
Adaptación web para dispositivos móviles se parece a las anteriores en la superficie y no se parece en nada por dentro. El catálogo la coloca en la categoría Diseño, le pone dificultad Principiante y la cotiza en $150 – $500 o 10 000 – 30 000 ₽ durante 6-16 horas. Su descripción no habla de tiempos en ningún momento: habla de que el sitio deja de descuadrarse en el teléfono, de que aparece un menú normal, de botones en los que se puede hacer clic, de texto legible, de formularios que funcionan, y de que la mayor parte del tráfico deja de caerse en la primera pantalla.
Un sitio puede pasar las tres métricas en verde y seguir siendo imposible de manejar con una mano en el autobús, y ese solo hecho ya separa las dos compras. El LCP, el INP y el CLS miden cuándo aparecen las cosas y cuánto tardan en responder; ninguno tiene una opinión sobre si el pulgar alcanza el menú o sobre si hay que ampliar con dos dedos para leer un precio. La combinación inversa se da con la misma frecuencia: maquetación impecable en cualquier pantalla, y lentísima. Elegir mal entre estas dos averías es la manera más habitual de gastarse el presupuesto sin que el usuario note nada.
Si el trabajo es de dificultad Principiante, ¿por qué el catálogo se reserva un margen de 6-16 horas, casi el triple de un extremo al otro? Porque las dos cifras no hablan de lo mismo. Principiante califica cada corrección por separado, y de hecho son rutinarias, de las que se resuelven sin inventar nada. Las horas cuentan repeticiones, y el número de repeticiones lo fija cuántas plantillas distintas tiene el sitio.
Una tienda con portada, listado de categoría, ficha de producto, carrito, proceso de pago, área de cliente y páginas de contenido reúne siete plantillas o más, cada una con sus puntos de ruptura y su forma propia de romperse. Una página única con cabecera, formulario y pie reúne una. Entre esos dos extremos está su presupuesto, y la cuenta la puede hacer usted antes de pedirlo, porque el número que importa es el de plantillas y no el de direcciones. Con ese número en la mano ya sabe si le corresponde el extremo bajo de 6-16 horas o el alto.
El contenedor PWA cambia la segunda visita, no la primera
Cuatro cosas cambian en el teléfono y ninguna de ellas es una promesa de calidad: el sitio se coloca en la pantalla de inicio, se abre sin la línea del navegador, funciona sin conexión y puede enviar mensajes push. Eso es literalmente lo que describe Contenedor PWA: sitio web como aplicación en el teléfono, en la categoría Móvil y con dificultad Con experiencia, por $100 – $400 u 8 000 – 25 000 ₽ en 6-14 horas. El catálogo añade el porqué comercial: sale decenas de veces más barato que una app nativa y no pasa por la moderación de las tiendas.
Todo eso lo hace una sola pieza, el service worker: un código que se instala entre el teléfono y su servidor y decide qué se sirve desde la caché y qué se vuelve a pedir. Escribirlo no es largo, y por eso la ficha tiene la horquilla en dólares más baja de este grupo. Equivocarse al delimitar qué guarda sí sale caro, y por eso la dificultad es Con experiencia y no Principiante. Una caché demasiado generosa le enseña los precios de ayer a quien vuelve, y recargar la página a mano no basta para quitárselos de encima.
El error caro con esta ficha es comprarla esperando que arregle una nota en rojo. No la arregla, y la razón está en la aritmética de las visitas: los datos de campo se agregan a partir de gente real, y en un sitio público una parte importante de esas visitas son primeras visitas, de usuarios que no han instalado nada. Para ellos la caché está vacía y la página tarda exactamente lo que tardaba. El contenedor mejora la segunda vez y todas las siguientes, que es un objetivo legítimo, pero es otro objetivo.
La pregunta útil, entonces, no es cuánto tráfico tiene, sino cada cuánto vuelve la misma persona. Con visitas semanales la inversión se amortiza sola; con una visita al año no se amortiza nunca. Encaja bien en seguimiento de pedidos, reservas y áreas de cliente, donde conservar sin conexión el último estado conocido resuelve algo real, y en equipos de campo que trabajan con cobertura irregular. Y encaja en el caso más frecuente de todos: clientes que piden una aplicación cuando lo que querían era un icono y un aviso, disponibles aquí en 6-14 horas sin desarrollo nativo ni revisión de tienda.
Del síntoma a la horquilla, leyendo hacia atrás
Con lo anterior ya puede recorrer usted el primer tramo del diagnóstico, sin escribirle a nadie: basta con traducir la frase de la queja. «La pantalla se queda en blanco un par de segundos y luego aparece todo de golpe» se traduce por LCP, con la causa en la primera pantalla y en el camino de renderizado, y con un arreglo de la forma de Green PageSpeed y Core Web Vitals, 5-12 horas. «Pulso un botón, no pasa nada, y después pasa todo a la vez» se traduce por INP, con la causa en el código que ocupa el hilo principal.
«Toqué donde no quería porque se movió bajo el dedo» se traduce por CLS, con la causa en el espacio que nadie reservó. Las dos frases siguientes se salen del mapa de las métricas. «El texto es diminuto y el menú se sale por el borde» corresponde a Adaptación web para dispositivos móviles, categoría Diseño, dificultad Principiante, 10 000 – 30 000 ₽ o $150 – $500, 6-16 horas. «Los clientes preguntan si tenemos aplicación» corresponde al contenedor PWA, $100 – $400, y se decide con datos de retorno en lugar de con una nota de velocidad.
Queda una comprobación que sirve para auditar el propio catálogo, ofrecida como ejemplo de razonamiento y no como tarifa publicada. Tome Green PageSpeed, $200 – $600 frente a 5-12 horas, y divida extremo bajo entre extremo bajo, y después extremo alto entre extremo alto. Los dos cocientes salen del mismo orden de magnitud, señal de que la horquilla responde al volumen de trabajo y no a lo que parezca que el cliente puede pagar. La operación se repite igual en cualquier otra ficha que publique dinero y tiempo a la vez.
Para que la primera conversación sea corta, mande tres cosas juntas. La dirección del sitio, de modo que las dos lecturas queden tomadas mientras nada se ha tocado todavía. El dispositivo desde el que llegan las quejas, porque móvil y escritorio fallan por motivos distintos y aquí el objetivo es el perfil móvil. Y la respuesta a si sabe nombrar la causa o solo el síntoma, que es lo que separa una pasada cotizada en horas de un diagnóstico; si la respuesta es «solo el síntoma», ese diagnóstico se vende suelto por 8 000–15 000 ₽ para que averiguarlo no obligue a comprar el resto.
Preguntas frecuentes
¿Cuánto cuesta poner los Core Web Vitals en verde?
Hay dos respuestas y la elección depende de si ya sabe qué falla. Con las causas identificadas, la ficha es Green PageSpeed y Core Web Vitals: $200 – $600 u 8 000 – 25 000 ₽ durante 5-12 horas. Si lo único que tiene es una nota en rojo, la que corresponde es Aceleración del sitio web y Core Web Vitals por debajo del umbral de Google, $200 – $800 o 10 000 – 40 000 ₽, organizada como 1 día de diagnóstico + 1 a 3 días de implementación, con INP hasta 200 ms, LCP hasta 2,5 s y CLS hasta 0,1 como objetivos.
¿Hace falta contratar la implementación si solo quiero entender las causas?
No, y por eso la investigación lleva precio propio: solo auditoría sin correcciones, 8 000–15 000 ₽, frente a los 10 000 – 40 000 ₽ del diagnóstico con implementación. El trabajo es el mismo en los dos casos y termina en el mismo listado priorizado de causas; lo que cambia es quién ejecuta después. A un equipo que ya tiene programadores en plantilla le basta con la primera opción.
¿Un contenedor PWA sube la nota de PageSpeed?
No, ni se vende con esa promesa. Contenedor PWA: sitio web como aplicación en el teléfono cuesta $100 – $400 u 8 000 – 25 000 ₽ durante 6-14 horas, y lo que entrega es instalación en la pantalla de inicio, apertura sin la línea del navegador, funcionamiento sin conexión y mensajes push. Un LCP en rojo se gana en la primera visita y la caché no interviene hasta la segunda, así que la velocidad se compra en fichas aparte.
¿En qué se diferencia la adaptación móvil del trabajo de velocidad?
En qué arregla cada una. Adaptación web para dispositivos móviles está en la categoría Diseño con dificultad Principiante y cuesta $150 – $500 o 10 000 – 30 000 ₽ durante 6-16 horas; ataca menús que no funcionan, botones que no se pueden pulsar, texto ilegible y formularios rotos. El trabajo de Core Web Vitals actúa sobre los tiempos de dibujado y de respuesta. Por eso un sitio puede estar en verde en las tres métricas y seguir siendo incómodo en el teléfono.