English
العربية
Deutsch
EspañolAuditoría técnica
Auditoría de Next.js
Una lectura de precio y alcance cerrados de una aplicación Next.js existente - renderizado, bundle, caché, ruta de render y despliegue - con un documento final ordenado por lo que cuesta cada cosa.
La mayoría de los encargos aquí empiezan con una. Un equipo sabe que algo va mal -la aplicación va lenta, no posiciona, o nadie despliega tranquilo- y quiere una respuesta concreta antes de comprometerse a un proyecto.
Un alcance cerrado y un precio cerrado, ambos acordados antes de empezar, y al final un documento que es tuyo continúes o no con nosotros.
Qué leemos
El modelo de renderizado. Qué rutas son estáticas, cuáles se volvieron
dinámicas y por qué. Una ƒ accidental en la salida del build es el hallazgo
más frecuente de todos, y suele ser una llamada a cookies() en un componente
compartido que te cuesta el CDN en todas las páginas por debajo.
La frontera de cliente. Dónde está use client, qué arrastra al bundle, y
cuál sería el First Load JS si estuviera un nivel más abajo.
Caché. En cuál de las cuatro capas está cada dato, si las etiquetas significan algo, y qué pasa en un redespliegue.
La ruta de render para buscadores. Qué recibe un rastreador frente a lo que aparece tras la hidratación; canónicos, el grupo de hreflang si lo hay, y si el sitemap está de acuerdo con el router.
Datos de campo. Core Web Vitals de visitantes reales en vez de una puntuación de laboratorio, ruta por ruta, con el elemento LCP identificado.
El camino de despliegue. Qué lo construye, qué tests corren, qué pasa cuando falla, y si queda alguien que lo sepa.
Qué te llevas
Un documento, no una presentación. Cada hallazgo tiene tres partes: qué está mal, qué cuesta en números que medimos, y qué implica arreglarlo. Ordenados por coste, no por etiqueta de severidad: una regresión de 400 ms de LCP en tu ruta con más tráfico va por delante de un problema teórico en una página que nadie visita.
Los hallazgos que podemos arreglar en menos de una hora los arreglamos durante la auditoría y te lo decimos. No vamos a facturar un proyecto por algo que era un cambio de una línea.
Lo que no es
No es un informe de Lighthouse con comentarios. Lighthouse lo puedes ejecutar tú; lo que no puedes hacer fácilmente es decidir cuáles de sus quejas importan para tu arquitectura, y ese juicio es el entregable.
Tampoco es un documento de venta. Algunas auditorías terminan con "esto está bien, el problema está en otro sitio". Preferimos escribir eso antes que fabricar un proyecto.
Después
Si los hallazgos apuntan a alguno de los otros servicios, el precio de la auditoría se descuenta de ese encargo. Si apuntan a trabajo que no hacemos, lo decimos y, cuando podemos, decimos quién lo hace.
La auditoría es también el primer mes de mantenimiento y soporte, si acabas ahí: es el mismo trabajo.
Cómo funciona
Mándenos el repositorio, una forma de ejecutarlo, y media hora con quien conozca la historia. El acceso a producción ayuda y no hace falta.
El precio se acuerda por escrito antes de empezar, en un alcance breve que dice qué vamos a leer y qué vamos a dejar en paz. No sube si la aplicación resulta estar peor de lo pensado, porque una auditoría que cuesta más cuanto peor es la noticia no es una sobre la que se pueda actuar.
Entre cinco y diez días laborables después llega el documento, con un recorrido. Lo que pase luego lo decide usted.