Salesforce y rendimiento web: cuándo la integración cuesta caro
Publicado el
Salesforce es la plataforma CRM más usada del mundo. Para muchas empresas, conectar su web a Salesforce parece el paso natural: los leads llegan directo al equipo comercial, los datos se sincronizan y el ciclo de ventas gana fluidez. El problema es que nadie evalúa el otro lado de la ecuación: qué le pasa a tu web cuando añades esa integración.
Formularios que tardan en cargar, scripts de tracking que bloquean el hilo principal, datos del contacto almacenados en dos sitios distintos con lógicas distintas. Estos costes no aparecen en la propuesta del partner de Salesforce, pero sí aparecen en tus Core Web Vitals, en tu tasa de conversión y en el aviso de tu DPO.
Este post no es contra Salesforce. Es a favor de tomar la decisión con criterio técnico, no solo funcional.
1. Qué ocurre cuando incrustas un formulario Web-to-Lead en tu web
La opción más básica de captura de leads en Salesforce se llama Web-to-Lead. Es una funcionalidad nativa que genera un fragmento de HTML listo para incrustar en tu web y que envía los datos al CRM cuando el usuario pulsa enviar.
Aquí empieza el primer problema de rendimiento: ese formulario no es tuyo. El HTML generado por Salesforce es funcional pero plano: sin clases útiles para tu sistema de diseño, sin gestión de estados de carga, sin estructura para mostrar errores o confirmación en el propio formulario. Añadir todo eso es trabajo manual. Pero el problema más crítico no es visual.
Cuando un usuario envía el formulario, el navegador hace una petición directa a los servidores de Salesforce y, una vez procesada, redirige al visitante a la URL de retorno que hayas configurado. Si esa petición tarda —por latencia de red o por carga puntual en la infraestructura de Salesforce—, el usuario espera con el botón de envío sin spinner ni estado intermedio. Tampoco hay forma estándar de mostrar un mensaje de error o de éxito en el propio formulario sin tocar el JavaScript a mano.
Eso son puntos de INP perdidos y una experiencia que no da señales de vida.
Y si el formulario está mal configurado (campos renombrados, validaciones de la org que rechazan el lead, reglas de assignment con condiciones que nadie revisó) puede fallar silenciosamente: el usuario ve la pantalla de éxito, pero el lead no llega a Salesforce. Sin monitorización activa, no te enteras hasta que alguien pregunta por qué nadie le ha contactado.
2. El script de tracking: el coste oculto que nadie menciona
Cuando la integración va más allá de Web-to-Lead y entra en Account Engagement (antes Pardot), aparece un nuevo actor: el tracking code. Es un snippet que se inserta en el <head> (o, según la implementación, antes del cierre de </body>) y que carga un script remoto desde la infraestructura de Salesforce para rastrear la navegación del visitante.
Cualquier script de terceros cargado en el hilo principal compite por los mismos recursos que el código de tu propia web, y el navegador lo trata como código que debe parsearse y ejecutarse antes de poder responder a la interacción del usuario. Si la ejecución es pesada o si el script lanza peticiones de red síncronas, los efectos son medibles: el LCP se retrasa porque el parser del navegador tiene que esperar; el INP empeora porque el hilo principal queda ocupado en momentos en que el usuario quiere interactuar; y si el servicio del tercero degrada o cae, tu propia web se ralentiza con él aunque tu servidor responda perfectamente.
Cómo mitigarlo sin eliminar el tracking
La solución no es siempre desactivar el script. Hay opciones intermedias:
- Cargarlo con
asyncodefersi la plataforma lo permite, para sacarlo del bloqueo de parseo. - Activarlo solo tras el consentimiento del usuario (necesario además por RGPD, ver sección 4).
- Usar un Tag Manager para controlarlo y poder auditarlo sin tocar el código base.
- Medir su impacto con PageSpeed Insights antes y después de añadirlo.
3. El problema de los datos duplicados: dos fuentes de verdad son ninguna
Uno de los patrones más comunes en pymes que integran Salesforce: el formulario de contacto vive en la web, pero la lógica de gestión de leads vive en Salesforce. El equipo comercial trabaja en Salesforce. El equipo de marketing, a veces, trabaja en la plataforma de email. Y el CMS del blog guarda sus propias analytics de conversión.
El resultado: el mismo contacto aparece en tres lugares distintos, con datos distintos, actualizado en fechas distintas.
Este no es un problema exclusivo de Salesforce, pero Salesforce lo amplifica porque tiene su propio modelo de datos (Lead → Contact → Account) que no encaja directamente con cómo tu web capta un prospecto. La conversión Lead → Contact suele depender de criterios de cualificación que viven dentro del CRM (assignment rules, scoring, automatizaciones), así que mientras esa lógica se ejecuta, tu web ya ha mostrado un mensaje de éxito al usuario y ha pasado a otra cosa. Si algo falla en el camino, la web no lo sabe.
Y si tienes deduplicación activa, un mismo contacto que rellena el formulario dos veces puede generar comportamientos inesperados: el segundo envío puede actualizar silenciosamente el registro existente sobreescribiendo campos, puede crear un Lead duplicado pendiente de fusión manual, o puede ser rechazado sin más. Cualquiera de esas tres opciones es una decisión, no un accidente, pero suele tomarse en una pantalla de configuración del CRM en la que el equipo de la web no tiene visibilidad.
Antes de integrar, define con claridad:
- ¿Dónde es la única fuente de verdad para el dato de un lead?
- ¿Qué sistema manda sobre el otro cuando hay conflicto?
- ¿Cuánto tiempo puede pasar entre que el lead llega a la web y que aparece en Salesforce?
4. RGPD: el tercero que nadie invitó a la reunión
Cuando integras Salesforce en tu web, los datos personales de tus usuarios ya no se quedan en tu servidor. Pasan a una infraestructura de una empresa americana, con su propio modelo de subprocesado, sus propias reglas de retención y, potencialmente, sus propias obligaciones legales bajo la jurisdicción estadounidense.
El RGPD no prohíbe esto, pero lo regula. Las transferencias de datos personales fuera del Espacio Económico Europeo solo son legales si el país receptor cuenta con una decisión de adecuación de la Comisión Europea o si la transferencia se ampara en mecanismos contractuales aprobados (cláusulas contractuales tipo, BCR, etc.).
Salesforce cubre esa parte: ofrece un Data Processing Addendum estándar con cláusulas contractuales tipo y opera bajo Binding Corporate Rules aprobadas. Para escenarios con requisitos estrictos de residencia de datos, Hyperforce EU Operating Zone permite que el tratamiento se realice dentro de infraestructura europea.
Pero ese marco contractual no se aplica solo: requiere trabajo activo por tu parte. Firmar el DPA con Salesforce, documentar las bases legales de cada tratamiento, configurar el banner de consentimiento para que el script de tracking solo se cargue si el usuario acepta, y mencionar a Salesforce como subencargado en tu política de privacidad. Si la implantación llega a producción sin esto resuelto, no tienes solo un problema de rendimiento: tienes uno de cumplimiento.
5. Cuándo la integración tiene sentido y cuándo no
Una integración Salesforce-web tiene sentido cuando el volumen de leads justifica la automatización y cuando el equipo comercial ya vive en Salesforce. Si tu equipo de ventas gestiona cientos de leads al mes, la fricción de mover datos manualmente supera con creces el coste de rendimiento de la integración.
No tiene sentido cuando:
- El negocio recibe pocos leads al mes y el equipo es pequeño. El overhead de mantenimiento de la integración (actualizaciones de API, gestión de errores silenciosos, duplicados) supera el beneficio.
- La web es principalmente informativa y el contacto llega por teléfono o email directo.
- No tienes capacidad técnica para monitorizar que la integración funciona. Una integración rota que nadie vigila es peor que no tener integración.
- El coste de la licencia de Salesforce no está justificado por el volumen de negocio. Cuantas más personalizaciones y terceros integras, más deuda técnica acumulas.
Checklist de evaluación previa a la integración
Antes de conectar tu web a Salesforce, responde estas preguntas:
Rendimiento
- ¿Has medido el LCP, INP y TTFB de tu página de contacto antes de añadir ningún script externo?
- ¿Sabes con qué atributo (
async/defero condicionado a consentimiento) se cargará el tracking code? - ¿Tienes un presupuesto de rendimiento definido que la integración no puede superar?
Datos
- ¿Tienes clara la fuente de verdad para el dato del lead en cada sistema?
- ¿Sabes qué pasa si el mismo email llega dos veces (deduplicación activada)?
- ¿Quién valida que los leads llegan realmente a Salesforce después del go-live?
RGPD
- ¿Tienes firmado el DPA con Salesforce?
- ¿Tus políticas de privacidad mencionan a Salesforce como subencargado del tratamiento?
- ¿El script de tracking se carga condicionado al consentimiento del usuario?
- ¿Has documentado la base legal de cada tratamiento de datos que implica la integración?
Mantenimiento
- ¿Quién se encarga de monitorizar que la integración sigue funcionando en 6 meses?
- ¿Tienes alertas si el formulario deja de enviar datos a Salesforce?
- ¿El coste de licencia + mantenimiento está justificado por el volumen de leads?
Alternativas para cuando Salesforce es demasiado
Si el análisis anterior revela que Salesforce es sobredimensionado para tu caso, hay alternativas con menor impacto en rendimiento y coste:
- Formulario propio + webhook a Salesforce: tu web controla la UX y el rendimiento del formulario; los datos se envían a Salesforce en segundo plano via API, sin bloquear la interacción del usuario.
- CRM más ligero: para volúmenes pequeños, herramientas como Brevo, HubSpot CRM gratuito o incluso una hoja de cálculo bien estructurada cubren el caso de uso sin añadir terceros pesados a tu web.
- Formulario nativo con notificación por email: el lead llega por email y alguien lo introduce manualmente en Salesforce. No escala, pero funciona para menos de 30 leads al mes y evita todos los problemas anteriores.
La integración con un CRM enterprise no es buena o mala en abstracto. Es cara o barata dependiendo de tu contexto. Si quieres evaluar el impacto que tiene tu stack actual en el rendimiento de tu web, puedes ver cómo trabajo la auditoría técnica antes de recomendar ningún cambio.