Qué cubre una auditoría de rendimiento de Drupal
Una auditoría de rendimiento de Drupal es una revisión puntual y con tiempo limitado de una plataforma Drupal frente a criterios de rendimiento. Produce una lista de hallazgos valorados y un conjunto priorizado de recomendaciones, cada una con una estimación de esfuerzo. El alcance abarca backend y frontend en un mismo trabajo, porque normalmente se miden por separado y se diagnostican juntos.
Las líneas de alcance se acuerdan por trabajo:
- Ruta de solicitud y respuesta del servidor: dónde se invierte el tiempo antes de que el primer byte salga del origen.
- Arquitectura de caché y renderizado: caché de página interna, caché de página dinámica, Redis o Memcache, proxy inverso, borde de CDN, BigPipe.
- Coste de base de datos y consultas: vistas y consultas programáticas caras, tablas sobredimensionadas, descarga de búsqueda.
- Entrega frontend y Core Web Vitals: LCP, CLS e INP, recursos que bloquean el renderizado, peso de scripts de terceros.
- Entrega de imágenes y recursos: formatos, estilos de imagen responsive, carga diferida, cabeceras de caché de recursos estáticos.
- Carga de tráfico y bots: cuánto del trabajo del origen es tráfico fraudulento y cuánto margen queda.
El tráfico autenticado y editorial está dentro del alcance junto con las páginas anónimas. Las intranets, las áreas de miembros y el back office son donde la caché a nivel de página deja de ayudar y el diagnóstico debe cambiar.
La auditoría está limitada en el tiempo por el presupuesto acordado. La cobertura, las URL de muestra y los accesos necesarios se fijan en la definición del alcance en lugar de dejarse abiertos como una revisión de cada página de la plataforma. Los hallazgos llegan valorados como Muy Alto, Alto, Medio o Informativo, para que la corrección pueda secuenciarse y presupuestarse en lugar de priorizarse desde una lista plana.
Han Confiado en Metadrop
Desde la fabricación y la distribución B2B hasta ONG humanitarias, asociaciones profesionales y administraciones públicas, organizaciones que operan en más de 50 países han confiado en Metadrop para el rendimiento, el almacenamiento en caché y el trabajo de infraestructura de Drupal.
Lo que dicen los clientes
Los propietarios de plataformas describen qué cambió una vez que el trabajo de rendimiento se midió en lugar de adivinarse.
Cuando una auditoría de rendimiento se paga sola
Si alguna de estas situaciones describe tu plataforma, la auditoría es el siguiente paso adecuado.
- Los tiempos de respuesta han variado y nadie puede señalar el cambio que lo provocó.
- Hay un pico de tráfico en el calendario: el lanzamiento de una campaña, un periodo de matriculación o admisiones, una temporada, unas elecciones, un ciclo de noticias de última hora.
- La visibilidad en buscadores está bajo presión y los Core Web Vitals aparecen en el diagnóstico. Los datos de campo son una señal de experiencia de página que Google utiliza, y tratarlos como la única causa de un cambio en el ranking sería exagerado.
- La plataforma fue heredada, asumida de un proveedor anterior o construida por personas que ya no están, sin una línea base de rendimiento documentada.
- Una agencia o integrador de sistemas necesita una lectura independiente de una plataforma de la que se ha hecho responsable, antes de comprometer un presupuesto de remediación.
- El departamento de compras solicita evidencia: las licitaciones del sector público y educativo valoran cada vez más el rendimiento de las páginas junto con la accesibilidad, y una auditoría evaluada es el documento que responde a esas exigencias.
- La productividad editorial es el síntoma: operaciones de guardado lentas, vistas de administración lentas, vistas previas lentas. El coste de back-office es un hallazgo de rendimiento por derecho propio.
La plataforma de un fabricante de electrodomésticos fue asumida de un proveedor anterior y auditada según criterios de seguridad, rendimiento, funcionalidad y accesibilidad. Los hallazgos definieron un plan de acción urgente, y a continuación se implementó una CDN y un WAF.
Las capas de caché y renderizado que diagnosticamos
La auditoría lee la pila de caché y renderizado como una arquitectura, capa por capa, y comprueba si cada capa está haciendo un trabajo que la capa superior ya ha realizado.
| Capa | Qué almacena | A quién sirve | Cómo se invalida | Cuándo activarla es la decisión correcta |
|---|---|---|---|---|
| Caché de página interna | Páginas renderizadas completas, guardadas en Drupal | Solo visitantes anónimos | Etiquetas de caché o un borrado manual; max-age no aplica | Sitios pequeños y medianos sin caché de proxy delante |
| Caché de página dinámica | La respuesta de la página excepto sus partes personalizadas | Visitantes anónimos y autenticados | Etiquetas de caché en la respuesta almacenada | Cualquier plataforma con tráfico de usuarios registrados |
| Caché de renderizado Redis o Memcache | Arrays de renderizado individuales: bloques, campos, resultados de vistas | Cada solicitud que tiene que reconstruir una página | Etiquetas de caché, más expulsión del backend cuando la memoria se llena | Cuando las reconstrucciones son frecuentes y el backend de caché de base de datos es el límite |
| Proxy inverso (Varnish) | Respuestas HTTP completas delante de Drupal, antes de que PHP se ejecute | Solo visitantes anónimos | Purga por etiqueta de caché mediante claves sustitutas, o por URL | Alto tráfico anónimo que no debería llegar al origen |
| Borde CDN | Respuestas completas y activos estáticos, en puntos de presencia cerca del visitante | Visitantes anónimos, en todas las regiones | Purga por clave sustituta o URL, más el cdn-cache-control max-age | Audiencias geográficamente dispersas, sitios con muchos activos, absorción de picos y bots |
Los ingenieros de Metadrop publican sobre la caché de página interna de Drupal y sobre la caché de estado en Drupal 10.3, que es el mismo material en el que se basa esta sección.
Caché de página interna
La caché de página interna atiende solo a usuarios anónimos, devolviendo una respuesta almacenada sin trabajo de renderizado. Dos aspectos de esta suelen sorprender a los equipos. max-age no se aplica: un max-age configurado no hará que se invalide por sí solo, por lo que la invalidación proviene de las etiquetas de caché o de una limpieza manual, y una etiqueta de caché personalizada invalidada según una programación es la solución documentada. Los contextos de caché no se aplican tampoco a las páginas que atiende, porque cada visitante anónimo recibe la misma respuesta.
Es más adecuada para sitios pequeños y medianos. Cuando ya hay una caché proxy delante de Drupal, dos capas realizan el mismo trabajo, y la práctica de Metadrop es deshabilitar la caché de página interna en entornos que tienen una caché proxy configurada. La auditoría registra qué capa está respondiendo realmente a cada URL muestreada, por lo que la recomendación se basa en el comportamiento observado y no en las pantallas de configuración.
Dynamic Page Cache y la cabecera X-Drupal-Dynamic-Cache
Dynamic Page Cache almacena en caché la respuesta de la página excepto las partes personalizadas, lo que la convierte en la capa que importa para el tráfico con sesión iniciada. Cada respuesta lleva X-Drupal-Dynamic-Cache con uno de tres valores: HIT, MISS o UNCACHEABLE.
Una página que pasa a UNCACHEABLE significa que Drupal ha decidido que la respuesta es poco cacheable. Tres causas principales explican la mayoría de los casos: un max-age igual o inferior al umbral configurado, un contexto de caché de alta cardinalidad o una etiqueta de caché de alta frecuencia de invalidación. La causa evitable más común es el user contexto de caché aplicado de forma demasiado amplia. Cuando el requisito es solo "diferente por visitante", session es más específico; cuando es solo "diferente por parámetro de consulta", url.query_args, o un único parámetro nombrado, es aún más específico.
La auditoría muestrea URLs en todas las plantillas e informa qué páginas no son cacheables y por qué, lo que convierte una queja sobre un sitio lento en una lista de correcciones.
Caché de render de Redis y Memcache
Las entradas de la caché de render se multiplican como el producto cartesiano de los contextos de caché de un componente. Un bloque que lleva languages:language_url, route y user en un sitio multilingüe grande puede alcanzar cientos de miles de entradas almacenadas, por lo que el diagnóstico clasifica los contextos por cardinalidad: url es muy alta, route y user son altas, languages:language_url y timezone son bajas.
Un puñado de causas se repiten y todas tienen solución. Los bloques de filtros expuestos de Vistas heredan el contexto url, un problema conocido del núcleo de Drupal. Las condiciones de visibilidad incorporan route. Los bloques de administración se dejan habilitados en el tema del frontend. La personalización del lado del servidor fuerza user. Cuando el contenido es lo bastante ligero para renderizarse por petición, el auto-placeholdering mantiene la caché de la página circundante en lugar de que el bloque la haga incacheable.
En Memcache, el hallazgo a vigilar es el límite de tamaño de objeto: los objetos que lo superan se dividen y almacenan en partes, lo que conlleva una penalización cuando ocurre con frecuencia.
La inestabilidad de la caché Redis de un fabricante de la industria alimentaria se atribuyó a una política de expulsión agresiva combinada con variaciones no limitadas en el contexto de la caché, tras lo cual se reconfiguraron los backends de Redis en los contenedores de caché de configuración, descubrimiento y formularios web y se eliminó una capa de caché duplicada en el proceso; la plataforma de un distribuidor B2B de productos de oficina utiliza Redis, invalidación de Varnish impulsada por purga y una CDN comercial como su línea base de caché habitual, mantenida bajo un compromiso continuo.
Coordinación de Varnish, CDN y purga
El comportamiento objetivo se comprueba explícitamente: solo se llega al origen cuando ninguna capa tiene una copia válida, y una URL modificada llega a los visitantes en su siguiente solicitud. Esto depende principalmente de la higiene de cabeceras, es decir, un valor cache-control que indique a los navegadores que deben revalidar, un cdn-cache-control (o s-maxage cuando la capa no lo admite) que lleve el max-age largo del borde, y un etag o last-modified presente para que una capa pueda validar sin consultar al origen.
También depende de la estrategia de purga: invalidación por etiqueta de caché cuando la capa admite claves sustitutas, o por URL cuando no las admite. El nombre de la cabecera de clave sustituta varía según el proveedor, y equivocarse es un fallo silencioso, ya que el contenido simplemente queda obsoleto. La invalidación de archivos y recursos se comprueba por separado de las páginas, porque los archivos pueden cambiar sin que cambie su URL.
Tres comprobaciones prácticas detectan la mayoría de los errores de configuración reales: si solo se almacenan en caché las respuestas anónimas, si la capa más externa ordena los parámetros de consulta para que una página no se almacene muchas veces, y si una capa interna filtra cdn-cache-control hacia afuera. Cuando la plataforma se ejecuta en una pila gestionada por el proveedor, el purgador del propio proveedor y su cola basada en cron se revisan como parte de la misma capa.
BigPipe y el marcado de posición
BigPipe transmite primero la estructura almacenable en caché de una página y rellena los fragmentos personalizados a medida que se renderizan, por lo que el tiempo de carga percibido mejora sin que las partes no almacenables en caché se vuelvan almacenables.
La auditoría mantiene separados el rendimiento percibido y el coste del origen como dos hallazgos: BigPipe cambia el primero, la estrategia de marcado de posición cambia el segundo. Los hallazgos nombran los componentes que merecen un marcado de posición, y aquellos donde el marcado de posición está ocultando una consulta que debería arreglarse en su lugar.
Picos de tráfico, bots y preparación para la carga
La pregunta que responde esta sección es cuánto margen queda, no la velocidad del sitio hoy en día.
Las pruebas de carga y estrés se ejecutan según un perfil acordado: concurrencia, rampa, las URLs y los recorridos autenticados que importan. Se ejecutan en un entorno que no es de producción, y los resultados se leen en función de la configuración de caché, no de forma aislada. Junto a esto, se sitúa el modelado de la forma del pico a partir de datos reales, utilizando el tráfico de campañas o temporadas anteriores, la tasa de aciertos de caché en el borde y la proporción de solicitudes que llegan al origen.
La carga de bots se mide como parte de la capacidad. El tráfico de rastreadores y scrapers de IA ha crecido hasta representar una parte real del trabajo del origen, por lo que un WAF más reglas en el borde es tanto planificación de capacidad como seguridad. La revisión de modos de fallo cierra la sección: qué ocurre cuando el origen se satura, si se puede seguir sirviendo contenido obsoleto y si las alertas se activan antes de que un visitante informe del problema.
Metadrop ha publicado análisis sobre el impacto del tráfico de bots en los sitios web y cómo mitigarlo, y sobre los requisitos del informe de estado de Drupal como señal de salud operativa.
El almacenamiento en caché no ajustado de un grupo químico multinacional estaba generando una carga pesada en sus servidores de origen, por lo que se aplicaron estrategias avanzadas de almacenamiento en caché a la búsqueda, los comunicados de prensa y el localizador de productos, y se añadió integración de purga para coordinar la invalidación entre Drupal, Varnish y la CDN, reduciendo las consultas al origen; en el mismo proyecto, el tráfico de bots maliciosos que causaba inestabilidad y costes adicionales de tráfico se mitigó con políticas de seguridad perimetral en la CDN y alertas, y los picos de tráfico falsos se redujeron aproximadamente un 90%, de unas 12.500 a 1.500 visitas a páginas. Una plataforma de comercio electrónico B2B de piezas industriales se colocó detrás de una CDN con reglas de ataque de bots y almacenamiento en caché de solicitudes anónimas, por lo que las solicitudes repetidas a páginas que no necesitan el origen dejan de llegar a él.
Entrega frontend, Core Web Vitals e INP
La medición cubre los tres Core Web Vitals actuales: LCP, CLS e INP. El INP sustituyó al FID como Core Web Vital en marzo de 2024, por lo que lo que se mide es la capacidad de respuesta a la interacción, no el retardo de la primera entrada. Los datos de campo y los de laboratorio se leen juntos, ya que las mediciones de campo con usuarios reales indican lo que experimentan los visitantes y el perfilado de laboratorio indica el porqué.
El diagnóstico del INP es un trabajo específico: tareas largas que bloquean el hilo principal, manejadores de eventos que realizan trabajo de maquetación, bibliotecas de hidratación pesada o de carruseles, y JavaScript cargado antes de ser necesario. A su alrededor se sitúan las conclusiones sobre la entrega. Bloqueo de renderizado y agrupación cubre si el CSS y el JavaScript están divididos por componente o se envían como un único paquete monolítico, qué hay en la parte superior del pliegue y qué se puede diferir. El peso de los scripts de terceros se inventaría con su propietario, de modo que los gestores de etiquetas, los widgets de chat, las herramientas de consentimiento, la analítica y los píxeles de marketing reciben cada uno un coste atribuido. La entrega de imágenes y recursos cubre formatos modernos, estilos de imagen responsive ajustados a los puntos de ruptura reales, carga diferida por debajo del pliegue, sugerencias de prioridad para el elemento LCP y cabeceras de caché de larga duración en recursos estáticos.
No se promete ninguna puntuación objetivo. El entregable es la lista de lo que está costando tiempo, en el orden en que merece la pena corregirlo.
La plataforma de una ONG humanitaria internacional tenía el CSS crítico incrustado, su imagen LCP precargada con una sugerencia de prioridad, conexiones tempranas abiertas a recursos externos, una biblioteca de carrusel heredada eliminada y la carga diferida reajustada, mejorando la estabilidad del diseño y el comportamiento de largest-contentful-paint; las imágenes se movieron a un formato más ligero con entrega optimizada para móvil.
Coste de base de datos, búsqueda y consultas
Las consultas costosas se localizan y atribuyen: vistas con filtros sin indexar, consultas programáticas en código de preprocesamiento o hooks, y consultas que se ejecutan en páginas almacenables en caché y que nunca deberían volver a ejecutarse. El crecimiento de las tablas también se trata como un hallazgo de rendimiento, porque los envíos de formularios, las revisiones de nodos, las revisiones de párrafos y las tablas de registros que alcanzan millones de filas afectan tanto a las copias de seguridad como a las migraciones y al coste de las consultas.
El registro en producción se revisa como una decisión arquitectónica: el registro en la base de datos en un sitio de alto tráfico crece rápidamente, y una canalización centralizada basada en syslog es el patrón sostenible. La descarga de la búsqueda plantea si la búsqueda compleja o facetada sigue ejecutándose contra la base de datos cuando un índice de búsqueda dedicado podría asumirla, y si el índice está actualizado y correctamente fragmentado. El trabajo de cron y colas abarca operaciones largas que pertenecen a lotes o procesos de consola en lugar de a una solicitud web.
Las brechas de observabilidad se notifican como hallazgos por derecho propio: sin datos agregados entre solicitudes, una página lenta aislada es una distracción, no un diagnóstico. Los ingenieros de Metadrop han publicado sobre la extensión del sistema de registro de Drupal con Monolog y sobre la lectura de cabeceras de respuesta HTTP como diagnóstico, ambas partes habituales de la revisión de esta capa.
El núcleo de búsqueda Solr de un grupo multinacional de ingeniería y construcción se actualizó a una versión mayor actual y su búsqueda se migró a un nuevo proveedor gestionado cuando la oferta gestionada anterior se interrumpió, manteniendo el rendimiento de la búsqueda en un servicio compatible durante la transición.
Cómo se ejecuta la auditoría y qué recibes
El trabajo se desarrolla en cuatro etapas, la última de ellas opcional:
- Definición del alcance: acordar los temas, las URLs de muestra, los recorridos a probar y los accesos y herramientas necesarios.
- Ejecución con tiempo limitado: realizar las comprobaciones sobre el alcance acordado y capturar las mediciones de referencia de las que dependerá toda comparación posterior.
- Presentación: exponer los hallazgos y las recomendaciones priorizadas a los miembros técnicos y no técnicos del grupo comprador, en un lenguaje que ambos puedan utilizar.
- Bucle de consultoría opcional: si está contratado, volver a medir los KPIs acordados comparándolos con la referencia de la auditoría con una cadencia acordada e informar del progreso. Cada KPI rastreado se remonta a una comprobación que estableció su referencia.
Lo que recibes es un informe de hallazgos con cada uno de ellos clasificado y vinculado a su evidencia, una lista de recomendaciones priorizadas con una estimación de esfuerzo por elemento para poder presupuestar la corrección y, si existe una fase de consultoría posterior, un informe recurrente comparado con la referencia.
| Criticidad | Qué significa la clasificación |
|---|---|
| Muy alta | Un bloqueante; no merece la pena corregir nada más antes. |
| Alta | Impacto significativo, corregir en la misma ronda. |
| Media | Merece la pena corregirla, agruparla. |
| Informativa | Registra un estado o una decisión deliberada; se informa, pero nunca se actúa sobre ella. |
Deliberadamente no existe el nivel Baja: un hallazgo que estaría en ese nivel es informativo o merece la pena agruparlo.
La auditoría es un diagnóstico, y la corrección es una decisión independiente. Las correcciones pueden ejecutarse como un proyecto o como trabajo evolutivo dentro de un contrato de mantenimiento de Drupal. La medición no es intrusiva, utiliza acceso de solo lectura además de una muestra acordada, y las pruebas de carga se ejecutan en un entorno que no es de producción. Los clientes que ya tienen un contrato de mantenimiento reciben una comprobación automatizada mensual sin coste adicional; una auditoría contratada es la versión en profundidad y revisada manualmente de esa comprobación.
Detrás del trabajo están las credenciales establecidas de Metadrop: más de 15 años de especialización en Drupal, estatus de Socio Certificado Silver de Drupal, certificación ENS y un historial de cumplimiento de GDPR, WCAG y NIS2, en plataformas que atienden a más de 50 países y 30 idiomas.
El dimensionamiento de la infraestructura y la selección del proveedor son una conversación aparte, así que consulta el alojamiento de Drupal cuando el hallazgo sea que la plataforma ha superado su plan. El rendimiento también es un tema dentro de la familia de auditorías y se puede combinar en un único trabajo con accesibilidad, SEO, UX/UI o GEO y AEO: un solo alcance, una sola presentación, una sola lista priorizada.
Preguntas frecuentes sobre auditorías de rendimiento
¿Por qué mi sitio Drupal es lento?
La lentitud en un sitio Drupal suele deberse a una de estas cuatro causas: páginas que no se pueden almacenar en caché, una capa de caché que duplica a otra, consultas que se ejecutan de nuevo en cada solicitud o peso del frontend en scripts e imágenes. La señal distintiva es quién es lento. Si los visitantes anónimos también son lentos, la causa suele ser la capacidad de almacenamiento en caché o el coste del origen; si solo los usuarios registrados son lentos, el diagnóstico se centra en el almacenamiento en caché de la representación y la personalización. Una auditoría de rendimiento sirve para sustituir esas conjeturas por mediciones y luego clasificar las causas por su impacto.
¿Cuál es la diferencia entre Varnish y la caché de páginas interna de Drupal?
Varnish es un proxy inverso situado delante de Drupal, que responde a las solicitudes anónimas sin que la solicitud llegue siquiera a PHP. Internal Page Cache es un módulo principal de Drupal que almacena las páginas renderizadas dentro de Drupal, también para usuarios anónimos. Ejecutar ambos significa dos capas haciendo el mismo trabajo, y la práctica de Metadrop es desactivar Internal Page Cache donde se configura una caché de proxy, manteniéndola para entornos de desarrollo si es necesario. Una cosa a comprobar antes de desactivarla: Internal Page Cache es lo que proporciona las cabeceras etag y last-modified, por lo que estas deben provenir de otro lugar una vez que esté desactivada.
¿Qué significa X-Drupal-Dynamic-Cache: UNCACHEABLE?
Una respuesta X-Drupal-Dynamic-Cache: UNCACHEABLE significa que Drupal consideró que la página no era lo suficientemente almacenable en caché, por lo que se reconstruye en cada solicitud. Tres causas explican la mayoría de los casos: una antigüedad máxima (max-age) igual o inferior al umbral configurado, un contexto de caché de alta cardinalidad como url o user, o una etiqueta de caché invalidada con mucha frecuencia. La cabecera se puede leer en el panel de red de cualquier navegador, lo que la convierte en el primer diagnóstico más económico en una página lenta de Drupal.
¿Cómo reduzco las entradas de caché de renderizado de Redis?
El número de entradas de caché de render de Redis se reduce al disminuir la cardinalidad del contexto de caché, no al aumentar la memoria, porque las entradas se multiplican como el producto cartesiano de los contextos de un componente. Comienza contando entradas por bin de caché y, dentro del bin más grande, por bloque, y luego lee los contextos que se muestran junto a cada uno. Las correcciones típicas son sustituir un contexto de URL o ruta por un contexto personalizado que devuelva solo las pocas variantes reales, mover la lógica de visibilidad de bloques a la capa del tema, cargar datos personalizados en el lado del cliente en lugar de añadir usuario, deshabilitar bloques de administración en el tema del frontend y forzar el auto-placeholdering en bloques ligeros cuyos contextos sean inevitables.
¿Cómo soluciono el INP en un sitio de Drupal?
El INP en un sitio Drupal se soluciona en el hilo principal: tareas largas, manejadores de eventos que realizan trabajo de layout y JavaScript que se ejecuta antes de la interacción a la que sirve. Los contribuyentes comunes específicos de Drupal son librerías pesadas de carruseles y sliders, paquetes monolíticos de JavaScript por página, plugins de la era de jQuery mantenidos para un solo componente y cargas de etiquetas de terceros que se disparan al cargar. La secuencia habitual es dividir el JavaScript en librerías por componente, diferir lo que no se necesita para la primera interacción, reemplazar los widgets pesados y luego volver a medir con datos de campo en lugar de una sola ejecución de laboratorio.
```
¿Puedes decirnos si el sitio sobrevivirá a nuestro próximo pico de tráfico?
La preparación para picos de tráfico se evalúa mediante pruebas contra un perfil de carga acordado: concurrencia, rampa, las URLs y los recorridos autenticados esperados, ejecutadas en un entorno no productivo y leídas junto con la configuración de caché y la tasa de aciertos en el borde. El resultado muestra dónde se satura primero la plataforma y qué cambiar antes de la fecha, en lugar de una cifra de capacidad certificada. El tráfico de bots y rastreadores se incluye en el perfil, porque una parte del trabajo de origen en el día pico no suele ser humano.
¿Cuánto tarda una auditoría de rendimiento de Drupal y afecta al sitio en vivo?
Una auditoría de rendimiento de Drupal se limita en el tiempo según el presupuesto acordado, que es lo que determina su duración: un alcance centrado en un único sitio se realiza en días, mientras que un gran sitio multisitio o multilingüe puede llevar semanas. La medición es no intrusiva, con acceso de solo lectura y una muestra de URL acordada en producción, mientras que las pruebas de carga y cualquier experimento que modifique la configuración se ejecutan en un entorno que no sea de producción. Lo que más acorta el cronograma es tener los accesos, los entornos y la lista de muestras preparados en la definición del alcance.
¿Cuánto cuesta una auditoría de rendimiento de Drupal?
Una auditoría de rendimiento de Drupal se presupuesta por proyecto, porque el tiempo es el producto: el presupuesto fija la profundidad de la revisión, y el alcance se acuerda antes de comenzar cualquier trabajo. Los factores que determinan el coste son el número de sitios e idiomas, el número de plantillas y recorridos distintos a muestrear, el tamaño y la antigüedad del código personalizado, y si se incluyen pruebas de carga. Las tarifas no se publican; una conversación sobre el alcance es lo que genera una cifra, y es esa misma conversación la que fija el alcance.