How We Build Custom Widgets for Our Blog

How we build custom widgets for our blog

In my personal opinion, the Widget Builder, available via the Custom Plan, is one of Duda’s most compelling features. Using little more than simple, industry-standard HTML you can create reusable widgets perfectly suited to meet any client’s needs. A quick look through our Experts portal highlights the potential. Agencies have built interactive galleries, custom shapes, and even scroll-progress bars using the powerful Widget Builder. We even do it ourselves for our own blog!

When we choose to build widgets, we do so to either make our blog posts more interactive, such as the “Copy” widget frequently used in our AI-oriented articles, or to cut back on some of our more repetitive tasks.

All good widgets have a few things in common:

The design is customizable
The widget is responsive
The code is easy to understand

With those three principals in mind, we’re going to build a custom bar graph widget together based on the very high quality, open source Chart.js library.

While some knowledge of HTML, CSS, and javascript may help you extract the maximum amount of value from this article—there’s plenty in here for beginners too. To sweeten the deal, the complete code will be available at the end.

That being said, if you’ve never built a custom widget before, this may not be the best place to start. Instead, take a look at our Duda University course covering this very same topic.

Ready to get started?

Conceptualize the widget

The first step in any good project is to fully understand your motivations and to clearly visualize your outcomes. Why are we building this widget? What do we hope to accomplish? How should it work? Answering these questions early in the process will help save us a lot of time later down the road.

For this particular project, we’re looking to create a reusable widget that can transform a table of data into a bar graph. With that in mind, it should have a somewhat customizable design, while still adhering to our style guides, and the ability to graph any arbitrary amount of data.

We’re going to be taking design inspiration from our “2024 AI Outlook for Digital Agency Leaders'' survey report, which includes a variety of well designed bar graphs. If you’re coding along, feel free to make the design your own.

Dig into the content and design editors

The Content Editor and Design Editor are what truly make Duda’s Widget Builder unique. Both of these tabs within the Widget Builder let us build a special form that can insert user-submitted data directly into our code. This is a crucial step towards making our widget reusable.

Content editor

Within the Content Editor, we know we know immediately that we’re going to need a “List” input. Lists let us create multiple miniature forms that we can access within the code as collections called “arrays.”

We’ll give our list a variable so that we can access it later, in this instance “barList,” and we’ll add three inputs within it: two text inputs and a dropdown. These text inputs will represent the bar’s Label with the variable chartLabel, and the bar’s value, with the variable chartValue. Since the bar’s value needs to be a number, we are going to add the following regular expression to the “validation regular expression” field.

The dropdown is optional, but we’ll be using it to define the bar’s color from a preselected list of options. You can take a peak at what this looks like in action via the screenshots below.

We’re going to include a few more fields in our Content Editor to help round-out our widget. These will include a text field for the chart’s title, a text field to label the data, a dropdown to pick the chart’s axis (x or y), a toggle to show or hide the legend, and a toggle to start the chart at zero or not. The table below shows all of the variables and labels we used.

Input type	Variable	Descriptive label
Text	chartTitle	Chart Title
Text	dataLabel	Data Label
Dropdown	chartAxis	Chart Orientation
Toggle	showLegend	Show Legend
Toggle	startZero	Start at Zero

Our dropdown includes two options in a “static list.”

Label	Value
Vertical	x
Horizontal	y

Design editor

The Design Editor works a little differently than the Content Editor. You can either create variable-post fields, like we did before, or you can create fields that directly interact with the css file.

Our first field is going to be one of the latter. We’ll add a “CSS Slider” input type to modify the padding of our entire element, which we’ll identify with the customer selector “#barChart.”

We’ll do this again with the “Rounded Corners” input type, also targeting the “#barChart” selector, as well as with the “Background” input type.

To spice things up, we’ll add two inputs that don’t interface with the CSS file. The first will be a toggle with the label “Show Ticks” and the variable “showTicks.” This will, as the name suggests, show or hide the tick marks on the chart.

We’ll also add a “Slider,” which is different from the CSS Slider we used earlier, labeled “Corner Radius” with the variable “chartRadius.” This will change the radius of the individual bars within the chart.

The final product should look something like the image below.

Write your HTML and CSS

As the name suggests, Chart.js is mainly a javascript library. That means we won’t be writing very much HTML or CSS in this project.

In fact, within our HTML file we’ll only be adding a single line of code.

The “canvas” element is a drawable area that the chart library can modify—something we’ll get to later in the javascript portion. The important thing to note here is that id value, “barChart.” You may recognize it from the Design Editor, and you’ll see it again in the CSS file.

Within our CSS file, we’ll add some version of the following code.

You can use any values you want here for border radius, padding, and background color. You’ll notice when we eventually preview this widget that the default values within the Design Editor are these numbers! Pretty neat trick, huh?

Write your javascript

Now the javascript is where things might get a little hairy. There are two unique things we need to do for this widget to work, we need to uniquely identify our canvas element and we need to load the Chart.js script.

If you have some experience writing code you might be thinking “isn’t the ID already unique?” It should be! However, if we happen to use this widget multiple times on the same page then this ID will be repeated—breaking our javascript.

Instead, we can use another unique aspect of the Widget Builder, the “element” parameter. Take a look at the following code.

This identifies our canvas element, but it does so only within the scope of this particular widget.

Now, to load the Chart.js library we’re going to use a feature of jQuery called “getScript.” It’ll look something like this.

This function loads our script and then, once it’s finished loading, calls a function. Within that function is where we’re going to call all of our code going forward.

First, we need to parse our list that we made in the Content Editor. If you remember, the list is going to contain labels, colors, and values. Chart.js needs all three of these things in their own unique, ordered collections—so that’s exactly what we’ll do.

JavaScript

 var chartLabels = [];
var chartColors = [];
var chartValues = [];
    
data.config.barList.forEach((item) => {
    chartColors.push(item.chartColor);
    chartLabels.push(item.chartLabel);
    chartValues.push(item.chartValue);
});

What we’re doing here is creating three buckets, then dividing our list items into each bucket. This is going to be useful in the next step, creating the chart.

Chart.js works by creating a “Chart,” like so.

JavaScript

 const myChart = new Chart(chart, {
    type: 'bar',
    data: {
        labels: chartLabels,
        datasets: [{
            label: data.config.dataLabel,
            data: chartValues,
            backgroundColor: chartColors,
            borderRadius: data.config.chartRadius
        }]
    },

...

Looking at the code above, you can see that we’ve defined the “type” as “bar.” You can also see where we’ve included the buckets we made earlier, in addition to the “dataLabel” and “chartRadius” fields we defined in the Content Editor and Design Editor, respectively.

This is essentially all you need to create a bar graph, but we’re going to take it a little further by customizing the design as well.

Immediately after that code, we’re going to add the following.

JavaScript

 ...

options: {
    indexAxis: data.config.chartAxis,
    responsive: true,
    maintainAspectRatio: false,
    scales: {
        x: {
            grid: {
                display: false,
                drawBorder: false
            },
            ticks: {
                display: data.config.showTicks
            }
        },
        y: {
            grid: {
                display: false,
                drawBorder: false
            },
            ticks: {
                display: data.config.showTicks
            },
            beginAtZero: data.config.startZero
        }
    },
    plugins: {
        title: {
            display: Boolean(data.config.chartTitle),
            text: data.config.chartTitle,
            align: 'start',
        },
        subtitle: {
            display: Boolean(data.config.chartTitle),
            text: " ",
            align: 'start'
        },
        legend: {
            display: data.config.showLegend,
            align: 'start'
        },
    }
}

Okay, so what’s happening here? First, we’re defining the “Index Axis,” which is the orientation we discussed in the Content Editor section. Then, we are making sure that our chart is responsive and also not confined to any particular aspect ratio. Then we start plugging in a few of the fields we defined earlier.

For this example, since we’re inspired by the design in the AI survey, we’re aligning our text to the start and hiding the grid. You don’t have to do that yourself.

The version we use on the Duda blog will take the design even further with custom fonts, tooltips, and more. The design customization here is virtually limitless. If you’re interested in diving deeper, take a look at the Chart.js documentation to explore just how many attributes you can customize.

Seeing it in action

Now that our widget is built, it’s time to use it! Here’s an example showing the most visited National Parks in 2023. As you can see, the Smoky Mountains were pretty popular last year.

Notice how the tooltip appears when you hover over each individual bar on the chart? This adds additional context and makes the entire widget a little more interactive than a normal image.

We said this needed to be customizable, and, thankfully, it is! Here’s another example graph comparing the length of our blog author’s names. This one uses a different color for the bars and switches up the orientation.

Ready to build your own widget?

The Widget Builder is an incredibly flexible tool for agencies looking to stretch the Duda platform to its limits. Duda Experts have been using this tool to create highly interactive, advanced tools for agencies to spice up their client’s sites.

Oh, and, as promised, the complete code for this widget is embedded below.

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.

Conceptualize the widget

Dig into the content and design editors

Content editor

Design editor

Write your HTML and CSS

Write your javascript

Seeing it in action

Ready to build your own widget?

Core web vitals: What agencies need to know in 2026

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

Maximizing SaaS growth with an API-driven website builder

Latest posts