Integración de Duda en una plataforma SaaS (3 de 3)

En los dos posts anteriores de esta serie, hemos trazado una hoja de ruta para generar mediante programación sitios web simples y permitirles a los usuarios de tu plataforma SaaS editar esos sitios en un entorno completamente white label.

También hemos hablado de la capacidad de empujar la información almacenada en tu aplicación a un sitio web como contenido. Esta visión general de las capacidades de Duda se centró en datos simples como números de teléfono, direcciones de email, horarios de trabajo, etc.

Mientras que esa información a nivel de negocio es obviamente importante para cualquier sitio web, los productos SaaS a menudo contienen estructuras de datos más complejas que necesitan ser expuestas al público. Este es el tema que trataremos ahora en este tercer y último post del blog de nuestra serie.

COLECCIONES

En Duda, las estructuras de datos complejas se pueden integrar a través de colecciones.

Una colección consiste en una lista de objetos similares (por ejemplo, miembros del personal, productos, eventos, noticias, etc.). Cada objeto de la lista consiste en un grupo de propiedades iguales.

En el caso de los miembros del personal, puede tratarse del nombre, la biografía o una foto de perfil. En el caso de eventos, podría ser una fecha, hora, descripción y URL para comprar ingresos.

A diferencia de los datos a nivel de negocio de los que hablamos en posts anteriores, los datos de las colecciones pueden ser enviados a Duda desde una fuente de datos pública en lugar de ser enviados a través de Duda API endpoint.

Duda puede comprobar los cambios en las colecciones de forma automática y actualizar el sitio web en el aire para asegurar que el contenido se mantiene sincronizado.

Los datos de las colecciones pueden conectarse a los widgets de la misma manera que conectamos nuestros datos a nivel empresarial. Sin embargo, debido a que los datos de las colecciones son una lista de elementos en lugar de una sola pieza de datos discretos, solo ciertos widgets son capaces de mostrar esos datos en una página.

Estos tipos de widgets incluyen el widget de lista, el widget de galería de fotos y el widget de acordeón, entre otros. Una vez conectada una colección, podrás conectar las propiedades individuales de los elementos para mostrarlos dentro del diseño del widget.

PÁGINAS DINÁMICAS

Junto con los widgets, las colecciones también pueden conectarse a páginas dinámicas. Con las páginas dinámicas, Duda puede generar una página completa por cada elemento de una colección.

Los ejemplos pueden incluir un directorio de personal o un catálogo de productos. Las páginas dinámicas pueden hacer que la creación de docenas o incluso cientos de páginas sea muy fácil.

Estas páginas se mantendrán sincronizadas con los datos de la colección, por lo que la actualización o eliminación de un elemento de la colección actualizará o eliminará su respectiva página.

TRABAJAR CON COLECCIONES EN UNA PLANTILLA

¿Recuerdas que en la primera parte de esta serie conectamos los widgets de una plantilla con los datos del marcador de posición almacenados en la biblioteca de contenidos?

Al proporcionar datos de marcador de posición, pudimos ver algunos contenidos que ayudan a tomar decisiones de diseño. Cuando se creaba un nuevo sitio basado en la plantilla, podíamos actualizar fácilmente los datos almacenados en la biblioteca de contenidos.

Cualquier widget conectado mostraría entonces la nueva información a través de las conexiones.

Al planificar una integración de SaaS, queremos hacer algo similar con colecciones. Dentro de la plantilla, especificaremos una URL a los datos del marcador de posición.

Podemos utilizar este marcador de posición para conectar nuestros widgets y diseñar páginas dinámicas. En el momento de la creación del sitio, actualizaremos el punto final de la colección para que apunte a los datos reales del usuario.

Mientras la colección esté formada por los mismos nombres de propiedad que la colección del marcador de posición, todos los widgets y las páginas dinámicas conectadas a la colección se actualizarán también.

Para crear una nueva colección en una plantilla, selecciona contenido en el menú de la izquierda. Selecciona collections y, a continuación, haz clic en el botón Nueva colección.

Se te presentará la opción de seleccionar el tipo de colección que deseas crear. Duda tiene la opción de crear una colección interna, donde los datos se gestionan dentro del editor, o una colección externa, en la cual los datos se gestionan desde una fuente externa.

Para nuestros propósitos, queremos conectarnos directamente a los datos de una plataforma SaaS. Así que nuestra colección debe estar conectada a una "Base de datos externa".

Recuerda que nos estamos conectando a una base de datos solo en concepto. Duda no hará llamadas directamente a través de una conexión de base de datos. Los datos reales deben estar disponibles a través de una URL pública.

Antes de proceder a la creación de la colección, tenemos que hablar del formato de los datos. Vamos a necesitar una URL de datos a la que nos conectaremos. La fase de diseño de la plantilla es un buen momento para reunir al diseñador y al desarrollador para hablar sobre qué información del producto SaaS debe estar disponible en el sitio web.

El resultado de esta reunión debería ser un archivo JSON estático al que el desarrollador pueda hacer referencia y que el diseñador pueda utilizar como datos de marcador de posición dentro de la plantilla. Lo importante es que los datos reales del cliente coincidan con el esquema del JSON del marcador de posición.

A modo de ejemplo, vamos a utilizar una plataforma SaaS ficticia para músicos. Uno de los tipos de datos recogidos en nuestro producto es la información sobre las próximas giras de los artistas.

Supongamos que nuestra hipotética empresa de SaaS reúne a un diseñador y a un desarrollador para comenzar a planificar la integración de Duda y se les ocurre la siguiente estructura JSON.

 {
  tour: {
    name: 'Please get me out of the house, post COVID tour!'
    id: '123',
    performances: [
      {
        id: 1,
        city: 'Palo Alto',
        date: 'June 8th',
        venue: 'Club Fox',
        address: '2209 Broadway Redwood City, CA 94063',
        startTime: '8:00pm',
        venueImage: 'https://example.org/path/to/image1.png',
        venueDescription: 'Small theater with a variety of music acts, a dance floor & a lounge area, with private events.',
        tickets: 'https://example.org/path/to/ticket/sales/1'
      }, {
        id: 2,
        city: 'Boulder',
        date: 'June 10th',
        venue: 'Boulder Theater',
        address: '2032 14th St, Boulder, CO 80302',
        startTime: '8:00pm',
        venueImage: 'https://example.org/path/to/image2.png',
        venueDescription: 'Art deco institution since 1906 for various music shows & mostly avant-garde films.',
        tickets: 'https://example.org/path/to/ticket/sales/2'
      }, {
        id: 2,
        city: 'Tel Aviv',
        date: 'July 10th',
        venue: 'Ozen Bar',
        address: 'King George St 48, Tel Aviv-Yafo, Israel',
        startTime: '8:00pm',
        venueImage: 'https://example.org/path/to/image3.png',
        venueDescription: 'The Hausenbar Club, part of the Third Ear Group, opened in 2008 and is still one of the rarest entertainment, music and art complexes in the country. From pop to pop, from techno to rock, from house to hip hop - Hausenbar is proud to host artists every week, beginners as veterans, a wide range of genres, parties led by the best DJs, and more.',
        tickets: 'https://example.org/path/to/ticket/sales/3'
      }
    ]
  }
}

Con una estructura de datos acordada, podemos volver a nuestra plantilla y terminar de crear nuestra colección. De vuelta en el editor hemos navegado a la página de la nueva colección. Aquí vamos a elegir la opción “External Database” para conectar una colección al archivo JSON que hemos acordado.

El archivo debe ser subido a un servidor web, o puedes usar algo como el servicio S3 de Amazon. Cualquier lugar en el que puedas obtener una URL y ver la salida JSON, debería funcionar.

(Nota: Esta URL debe devolver datos con un valor de encabezado Content-Type de "application/json", ya que otros tipos de contenido darán lugar a un error al crear la colección).

En la pantalla de la nueva colección, introduce la URL de tu archivo JSON en el campo "Endpoint URL". También podrás expandir una opción para definir la ruta real de los datos dentro del punto final.

Si volvemos y hacemos referencia a nuestro JSON, veremos que la lista de actuaciones está en realidad dentro de la propiedad "performances", que a su vez está dentro de la propiedad "tour". En este caso, introduciríamos "tour.performances", como la ruta de acceso a nuestros elementos.

Una vez que hayamos configurado nuestro endpoint, podemos hacer clic en el botón "Fetch Collection" para confirmar que todo funciona correctamente. Si Duda es capaz de encontrar una colección, el primer elemento de la lista se mostrará como una vista previa. Asegúrate de confirmar que los datos sean correctos antes de continuar.

Debajo de la vista previa, verás una opción para elegir qué propiedad de tu colección quieres utilizar como URL del elemento de la página. La propiedad que elijas se utilizará en la URL de las páginas dinámicas.

En nuestro ejemplo del tour, podríamos elegir la propiedad "id" para generar rutas similares a "/tour/1", "tour/2", etc. (más adelante veremos cómo configurar la parte "tour" de la URL).

La siguiente pantalla nos permite elegir el tipo de dato para cada propiedad de nuestra colección. Este paso de configuración le indica al editor de Duda qué propiedades pueden conectarse a qué widgets.

Por ejemplo, configurando la propiedad "dirección" en la colección para que sea un tipo de dato de "ubicación", hará que esta propiedad esté disponible cuando se conecte una actuación a un widget de mapa.

Actualiza cada propiedad de la colección con el tipo de datos correcto y haz clic en "done".

¡Felicitaciones! Acabamos de configurar nuestra primera colección.

TRABAJAR CON PÁGINAS DINÁMICAS EN UNA PLANTILLA

Ahora que hemos importado algunos datos, vamos a ver cómo podemos crear algunas páginas nuevas basadas en la información.

Al vincular nuestra colección a las páginas dinámicas, nos aseguraremos de que la información en el sitio web esté siempre sincronizada con la información en la plataforma SaaS. No tendremos que preocuparnos nunca de que los visitantes del sitio web reciban datos desactualizados.

La creación de una página dinámica es similar a la creación de una página estática en un sitio web de Duda. Selecciona "páginas" y luego haz clic en "nueva página" para ver el modo de la nueva página.

Este modo presenta algunos diseños de uso común listos para ser rellenados con datos.

Después de añadir una página dinámica, el editor la colocará en "modo dinámico". Esto significa que cualquier cambio que hagas en esta página se reflejará en todas las demás páginas dinámicas.

Aquí eres libre de hacer ajustes de diseño al igual que en cualquier otra página de Duda. También puede conectar los datos a cualquiera de los widgets de la página utilizando los mismos pasos que utilizamos para conectar los datos empresariales.

Sin embargo, si seleccionas una propiedad de una colección, el valor cambiará para cada página generada por la colección. Esto nos permite crear múltiples páginas con el mismo diseño, pero con diferente contenido.

PROPORCIONAR NAVEGACIÓN A LAS PÁGINAS DINÁMICAS

Los links a tus nuevas páginas pueden hacerse conectando con un widget compatible con la colección, como el widget de lista, o proporcionando links directamente en tu navegación.

Solo tienes que volver a la pestaña "páginas" y hacer clic en el icono del engranaje junto a tu página dinámica. El menú desplegable tiene una opción para ocultar o mostrar las páginas en la navegación.

Te daremos la opción de añadir las páginas dinámicas como una subnavegación a una página existente. También podrás elegir qué propiedad de tu colección debe utilizarse como texto de navegación.

ACTUALIZACIÓN DE LA COLECCIÓN CON DATOS EN EL AIRE

Ahora que la plantilla está actualizada para incluir páginas dinámicas. Podemos volver a centrar nuestra atención en el flujo de creación del sitio web. Como repaso aquí está la lista de pasos de los artículos anteriores.

Crear un sitio web a partir de una plantilla
Actualizar la biblioteca de contenidos con los datos del negocio
Crear una cuenta de usuario
Conceder acceso al sitio web

Mientras que el diseñador ha trabajado duro en la creación de la plantilla, nuestro desarrollador ha tenido tiempo de desenvolver los datos en una URL pública. Asumiendo que todo está listo para funcionar, vamos a añadir una llamada adicional a la lista para actualizar el punto final de la colección para que apunte a los datos en vivo.

Cada sitio web tendrá una URL que proporciona datos sobre una sola cuenta de tu producto. El formato depende de ti. Podría ser a través de parámetros de ruta como "/cliente/1/nombre_de_la_colección". También puedes utilizar un parámetro de consulta para filtrar los elementos como "/nombre_de_colección?cliente=1". solo tiene que estar disponible a través de una petición GET estándar.

 
curl --request PUT \ 
--url https://api.duda.co/api/sites/multiscreen/{site_name}/collection/{current_collection_name}
 \ 
--header 'authorization: Basic123abc=' \ 
--header 'content-type: application/json' \ 
--data '{
  "external_details": {
      "enabled": true,
      "external_endpoint":"https://example.org/artists/1/tour",
      "page_item_url_field": "id",
      "collection_data_json_path": "tour.performances"
  },
  "name":"Performances"
}'

Nota: Actualizar una colección con un nuevo punto final. Siempre debes proporcionar valores para cualquier propiedad existente, incluso si el nuevo valor es igual al existente. Si no se envían valores para propiedades como page_item_url_field, collection_data_json_path, etc. resultará en la eliminación del valor existente.

AHORA COLOQUEMOS TODO JUNTO

Ahora tenemos todas las piezas para crear instantáneamente un sitio web bonito y útil. Aunque son muchos pasos para escribir, en la práctica, solo necesitas implementar un puñado de llamadas a la API.

También es fácil que se trabaje simultáneamente en diferentes caminos de tu implementación. Tu diseñador puede trabajar en las plantillas mientras un desarrollador se pone a trabajar en la superficie de los datos para tus colecciones.

Otro diseñador o desarrollador puede trabajar en el white label. Y, por último, se podría asignar a alguien la implementación de la interfaz de usuario y las llamadas a la API dentro de la propia aplicación SaaS. Al paralelizar el trabajo, se puede realizar una implementación muy rápidamente.

He aquí una lista completa de los pasos, divididos en caminos de trabajo separados:

Editor Duda
Etiqueta la interfaz de usuario de Duda y configurar los dominios para el editor y los subdominios del sitio, por defecto.
Crea una selección de plantillas utilizando datos de marcador de posición. Conectar los widgets a los datos de la empresa o a las colecciones de la biblioteca de contenidos.
Infraestrutura SaaS
Desarolla los datos relevantes de la colección en los puntos finales públicos.
Interfaz de usuario de la aplicación SaaS
Proporciona la interfaz de usuario y las llamadas a la API para el flujo instantáneo del sitio web

Esta serie proporciona una hoja de ruta estándar para crear sitios web totalmente funcionales mediante programación a través de tu aplicación SaaS, pero hay espacio para la personalización. ¿Quieres que los sitios se publiquen inmediatamente o quieres que tus usuarios los personalicen primero? ¿Vas a cobrarles a los usuarios antes de que accedan al editor, o quieres una experiencia de "probar antes de comprar" en la que la transacción no se produce hasta que el usuario intente publicar el sitio? ¿Tienes funciones interactivas que te gustaría que vinieran preconfiguradas en los nuevos sitios a través de un widget personalizado? Hay mucho que pensar, pero por suerte, Duda puede proporcionarte una gestión de cuenta dedicada para ayudarte en cada paso y decisión.

¿Necesitas un poco de ayuda? Duda también tiene un canal de cumplimiento de los profesionales de la web que pueden ayudar a diseñar y construir tus plantillas.

Si estás interesado en ofrecer sitios web a través de tu plataforma SaaS, ¡Entra en contacto con nuestro equipo hoy mismo!

Agora temos todas as peças para criar instantaneamente um site bonito e de alta performance. Embora sejam muitas etapas para descrever, na prática, você só precisa implementar algumas chamadas de API. Também é fácil trabalhar em diferentes frentes de implementação simultaneamente. Seu time de designers pode trabalhar em modelos enquanto desenvolvedores começam a trabalhar na camada de dados das suas coleções. Outros profissionais de design e desenvolvimento podem estar trabalhando em seu White Label. E, finalmente, alguém pode estar implementando as chamadas de UI e API dentro da própria plataforma SaaS. Ao distribuir e organizar tarefas, uma implementação poderá acontecer muito rapidamente.

Aqui está uma lista completa das etapas, divididas por tópicos organizados:

Editor da Duda
Configure seu White Label para a interface do usuário na Duda, e configure os domínios para o editor e os subdomínios do site padrão.
Crie uma seleção de templates usando dados como placeholders. Conecte widgets a dados ou coleções na biblioteca de conteúdo.
Infraestrutura SaaS
Exiba dados relevantes da coleção nos endpoints públicos.
UI (Interface do usuário) do seu SaaS
Forneça UI e chamadas API para o fluxo de websites instantâneos:
Crie o site
Crie o usuário da conta
Conceda acesso ao site
Atualize os dados de negócio na biblioteca de conteúdos
Atualize os endpoints das coleções
Publique imediatamente (opcional)
Forneça acesso SSO (Single Sign-on) para o editor de website (opcional)

Esta serie proporciona una hoja de ruta estándar para crear sitios web totalmente funcionales mediante programación a través de tu aplicación SaaS, pero hay espacio para la personalización.

¿Quieres que los sitios se publiquen inmediatamente o quieres que tus usuarios los personalicen primero?

¿Vas a cobrarles a los usuarios antes de que accedan al editor, o quieres una experiencia de "probar antes de comprar" en la que la transacción no se produce hasta que el usuario intente publicar el sitio?

¿Tienes funciones interactivas que te gustaría que vinieran preconfiguradas en los nuevos sitios a través de un widget personalizado?

Hay mucho que pensar, pero por suerte, Duda puede proporcionarte una gestión de cuenta dedicada para ayudarte en cada paso y decisión.

¿Necesitas un poco de ayuda? Duda también tiene un canal de cumplimiento de los profesionales de la web que pueden ayudar a diseñar y construir tus plantillas.

Si estás interesado en ofrecer sitios web a través de tu plataforma SaaS, ¡Entra en contacto con nuestro equipo hoy mismo!

Lea también:

Integración De Duda En Una Plataforma SaaS (1 De 3)

Integración De Duda En Una Plataforma SaaS (2 De 3)

Core web vitals: What agencies need to know in 2026

By Shawn Davis • April 1, 2026

Core Web Vitals aren't new, Google introduced them in 2020 and made them a ranking factor in 2021. But the questions keep coming, because the metrics keep changing and the stakes keep rising. Reddit's SEO communities were still debating their impact as recently as January 2026, and for good reason: most agencies still don't have a clear, repeatable way to measure, diagnose, and fix them for clients. This guide cuts through the noise. Here's what Core Web Vitals actually measure, what good scores look like today, and how to improve them—without needing a dedicated performance engineer on every project. What Core Web Vitals measure Google evaluates three user experience signals to determine whether a page feels fast, stable, and responsive: Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image or headline — to load. Google considers anything under 2.5 seconds good. Above 4 seconds is poor. Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. Where FID measures the delay before a user's first click is registered, INP tracks the full responsiveness of every interaction across the page session. A good INP score is under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability — how much page elements unexpectedly move while content loads. A score below 0.1 is good. Higher scores signal that images, ads, or embeds are pushing content around after load, which frustrates users and tanks conversions. These three metrics are a subset of Google's broader Page Experience signals, which also include HTTPS, safe browsing, and mobile usability. Core Web Vitals are the ones you can most directly control and improve. Why your clients' scores may still be poor Core Web Vitals scores vary dramatically by platform, hosting, and how a site was built. Some of the most common culprits agencies encounter: Heavy above-the-fold content . A homepage with an autoplay video, a full-width image slider, and a chat widget loading simultaneously will fail LCP every time. The browser has to resolve all of those resources before it can paint the largest element. Unstable image dimensions . When an image loads without defined width and height attributes, the browser doesn't reserve space for it. It renders the surrounding text, then jumps it down when the image appears. That jump is CLS. Third-party scripts blocking the main thread . Analytics pixels, ad tags, and live chat tools run on the browser's main thread. When they stack up, every click and tap has to wait in line — driving INP scores up. A single slow third-party script can push an otherwise clean site into "needs improvement" territory. Too many web fonts . Each font family and weight is a separate network request. A page loading four font files before rendering any text will fail LCP, especially on mobile connections. Unoptimized images . JPEGs and PNGs served at full resolution, without compression or modern formats like WebP or AVIF, add unnecessary weight to every page load. How to measure them accurately There are two types of Core Web Vitals data you should be looking at for every client: Lab data comes from tools like Google PageSpeed Insights, Lighthouse, and WebPageTest. It simulates page loads in controlled conditions. Lab data is useful for diagnosing specific issues and testing fixes before you deploy them. Field data (also called Real User Monitoring, or RUM) comes from actual users visiting the site. Google collects this through the Chrome User Experience Report (CrUX) and surfaces it in Search Console and PageSpeed Insights. Field data is what Google actually uses as a ranking signal — and it often looks worse than lab data because it reflects real-world device and connection variability. If your client's site has enough traffic, you'll see field data in Search Console under Core Web Vitals. This is your baseline. Lab data helps you understand why the scores are what they are. For clients with low traffic who don't have enough field data to appear in CrUX, you'll be working primarily with lab scores. Set that expectation early so clients understand that improvements may not immediately show up in Search Console. Practical fixes that move the needle Fix LCP: get the hero image loading first The single most effective LCP improvement is adding fetchpriority="high" to the hero image tag. This tells the browser to prioritize that resource over everything else. If you're using a background CSS image for the hero, switch it to anelement — background images aren't discoverable by the browser's preload scanner. Also check whether your hosting serves images through a CDN with caching. Edge delivery dramatically reduces the time-to-first-byte, which feeds directly into LCP. Fix CLS: define dimensions for every media element Every image, video, and ad slot on the page needs explicit width and height attributes in the HTML. If you're using responsive CSS, you can still define the aspect ratio with aspect-ratio in CSS while leaving the actual size fluid. The key is giving the browser enough information to reserve space before the asset loads. Avoid inserting content above existing content after page load. This is common with cookie banners, sticky headers that change height, and dynamically loaded ad units. If you need to show these, anchor them to fixed positions so they don't push content around. Fix INP: reduce what's competing for the main thread Audit third-party scripts and defer or remove anything that isn't essential. Tools like WebPageTest's waterfall view or Chrome DevTools Performance panel show you exactly which scripts are blocking the main thread and for how long. Load chat widgets, analytics, and ad tags asynchronously and after the page's critical path has resolved. For most clients, moving non-essential scripts to load after the DOMContentLoaded event is a meaningful INP improvement with no visible impact on the user experience. For websites with heavy JavaScript — particularly those built on frameworks with large client-side bundles — consider breaking up long tasks into smaller chunks using the browser's Scheduler API or simply splitting components so the main thread isn't locked for more than 50 milliseconds at a stretch. What platforms handle automatically One of the practical advantages of building on a platform optimized for performance is that many of these fixes are applied by default. Duda, for example, automatically serves WebP images, lazy loads below-the-fold content, minifies CSS, and uses efficient cache policies for static assets. As of May 2025, 82% of sites built on Duda pass all three Core Web Vitals metrics — the highest recorded pass rate among major website platforms. That baseline matters when you're managing dozens or hundreds of client sites. It means you're starting each project close to or at a passing score, rather than diagnosing and patching a broken foundation. How much do Core Web Vitals actually affect rankings? Honestly, they're a tiebreaker — not a primary signal. Google has been clear that content quality and relevance still dominate ranking decisions. A well-optimized site with thin, irrelevant content won't outrank a content-rich competitor just because its CLS is 0.05. What Core Web Vitals do affect is the user experience that supports those rankings. Pages with poor LCP scores have measurably higher bounce rates. Sites with high CLS lose users mid-session. Those behavioral signals — time on page, return visits, conversions — are things search engines can observe and incorporate. The practical argument for fixing Core Web Vitals isn't just "because Google said so." It's that faster, more stable pages convert better. Every second of LCP improvement can reduce bounce rates by 15–20% depending on the industry and device mix. For client sites that monetize through leads or eCommerce, that's a revenue argument, not just an SEO argument. A repeatable process for agencies Audit every new site before launch. Run PageSpeed Insights and record LCP, INP, and CLS scores for both mobile and desktop. Flag anything in the "needs improvement" or "poor" range before the client sees the live site. Check Search Console monthly for existing clients. The Core Web Vitals report surfaces issues as they appear in field data. Catching a regression early — before it compounds — is significantly easier than explaining a traffic drop after the fact. Document what you've improved. Clients rarely see Core Web Vitals scores on their own. A monthly one-page performance summary showing before/after scores builds credibility and makes your technical work visible. Prioritize mobile. Google uses mobile-first indexing, and field data shows that mobile CWV scores are almost always worse than desktop. If you only have time to optimize one version, do mobile first. Core Web Vitals aren't a one-time fix. Platforms change, new scripts get added, campaigns bring in new widgets. Build the audit into your workflow and treat it like any other ongoing deliverable, and you'll stay ahead of the issues before they affect your clients' rankings. Duda's platform is built with Core Web Vitals performance in mind. Explore how it handles image optimization, script management, and site speed automatically — so your team spends less time debugging and more time building.

Why systems, not tools, are the future of vertical SaaS

By Ilana Brudo • March 31, 2026

Vertical SaaS must transition from tools to an AI-powered Vertical Operating System (vOS). Learn to leverage context, end tech sprawl, and maximize retention.

Maximizing SaaS growth with an API-driven website builder

By Shawn Davis • March 27, 2026

Automate client management, instant site generation, and data synchronization with an API-driven website builder to create a scalable growth engine for your SaaS platform.