How To Use a CSS Grid Template Area & Why It Can Save You Time

For website professionals, saving time on website builds and mockups is a must to stay competitive and profitable. One way to satisfy this business need is to use CSS grid templates and CSS grid template areas.

Many modern websites are built using grids, which divide a page into major regions and define the relationship between elements in terms of size, position, and layer. Grids make it easy to place elements into both columns and rows.

This means that whether you use code to create a CSS grid template, choose from grid template starters, use a theme built via grids, or use some plug-and-play design elements in a website builder like Duda, it pays to understand how CSS grid templates and grid template areas work.

The power of CSS grid is incorporated into Duda’s editor via DudaFlex sections, which enable digital marketing agencies and their customers to create pixel-perfect designs at breakneck speed inside our intuitive drag-and-drop site editor. With DudaFlex, you get the power of CSS grid-based designs in a fraction of the time it would take to develop them using the traditional coding methods outlined below.

CSS Grid Template Area Basics

A CSS grid template area makes a visual representation of the grid using both columns and rows. This makes for a faster design process than when line-based placement or grid-column and grid-row values are used.

Why?

Using line-based placement isn’t as streamlined as grid template areas. And, as UI/UX Designer & Front-End Developer Ahmad Shadeed points out, when you change one element in grid-column, like the width of the sidebar span, you also have to individually change the width of the footer, main element, and other elements.

With a CSS grid template area, you set the width in a single command and then the placements of the grid cells — and everything adjusts accordingly.

Another benefit to CSS grid template areas: they are responsive.

How To Use CSS Grid Template Areas

To reap the time saving benefits of designing with this method, build a CSS grid template and name your CSS grid template areas in two CSS coding steps. Common grid template areas to specify include header, menu, footer, sidebar, main content, etc. Once these are set up, they’re easy to move around within your grid template.

First, define names of your grid template areas with the grid-area property. This sets up the next step, which will create the grid-template layout.

For instance, below is an example from Mozilla that sets the grid areas with shortcuts for header, footer, content, and sidebar.

Second, use grid-template areas property to define how the areas appear in the rows and columns. This creates your easy-to-use webpage template.

For instance, in the example below from Mozilla, the first line command sets the display as a grid. In the next line command, the columns are defined as “9” items long. In the next line command, the rows are set. Then, the CSS grid template areas are given their arrangements.

 wrapper {
    display: grid;
    grid-template-columns: repeat(9, 1fr);
    grid-auto-rows: minmax(100px, auto);
    grid-template-areas:
      "hd hd hd hd   hd   hd   hd   hd   hd"
      "sd sd sd main main main main main main"
      "ft ft ft ft   ft   ft   ft   ft   ft";
}

As you see in the code above, you need to use the grid-template areas (names of your content areas) multiple times to add up to the number of columns in your grid template. The header “hd” above gets all nine widths in the column. In the next row, the sidebar as defined as “sb” in the code above gets three widths in the column, and the main content gets six widths of the column. In the third row, the footer gets all nine column widths.

Here is the HTML that follows the CSS. The HTML populates the grid template with the actual content.

And here is the result:

a diagram of a web page showing the header, sidebar, content area and footer.

Understanding the Code

You can use the shorthand CSS fraction code (fr), meaning fraction of the free space. The fraction command eliminates overflow on the x-axis even when you set a grid-column-gap value. With the fraction command, when, as in the above example, you set each column to “1fr,” the grid accounts for the grid-column-gap value and subtracts it from the total width for each column.

You can also use the shorthand repeat code like above to make the columns repeat. For example, “grid-template-columns:repeat (9, 1fr);” shows the combined commands that specify the fraction code and the number of columns. For 6 columns or 12 columns or 15 columns, you would change the value after it repeats.

You also can easily control other ways the grid template appears.

For instance:

You can set the grid-gap.
You can set a background color.
You can set padding.

Here’s another example, which uses the “container” command instead of the “wrapper” command.

 .item-1 {
  grid-area: head;
}
.item-2 {
  grid-area: main;
}
.item-3 {
  grid-area: side;
}
.item-4 {
  grid-area: footer;
}

.container {
  display: grid;

  grid-template-columns: 2fr 2fr 1fr 2fr;
  grid-template-rows: 100px 200px 100px;

  grid-template-areas:
    "head head . side"
    "main main . side"
    "footer footer footer footer";
}

When the HTML with the actual content (not included in the above code) is added to this CSS grid template, it will result in:

a diagram of a web page showing the header, main area, sidebar and footer.

The above example uses additional shortcuts where the dot represents an empty grid shell.

You can do a ton with this quickly by only changing a tiny bit of the code. For the above, you can completely revamp the layout to look like this:

a diagram of a website with a header, main area, sidebar and footer .

The only code that changed were where the spaces (using dots) land in the template — see below:

Let's Play With CSS Grid Templates

There’s even more you can quickly accomplish once you name CSS grid template areas and create a template. For instance, you can also set a column that doesn’t change values followed by columns that do. Here’s how the code would be different with the first column set at 250px followed by repeating columns set by fraction of free area:

What makes CSS grid template areas really stand out is you can make them fully responsive by adding a snippet of additional code. With CSS grid templates, you can easily tell the design how to respond based on a device’s pixel width and height.

Here’s an example from Mozilla:

 @media (min-width: 500px) {
    .wrapper {
        grid-template-columns: repeat(9, 1fr);
        grid-template-areas:
          "hd hd hd hd   hd   hd   hd   hd   hd"
          "sd sd sd main main main main main main"
          "sd sd sd  ft  ft   ft   ft   ft   ft";
    }
}
@media (min-width: 700px) {
    .wrapper {
        grid-template-areas:
          "hd hd hd   hd   hd   hd   hd   hd hd"
          "sd sd main main main main main ft ft";
    }
}

This results in two columns when the screen is at least 700 pixels but three columns when the screen is smaller. (Note: The template areas were defined in separate code not affected by the additional media query code.)

The below example takes the Alligator.io layout above and makes it work on smaller screens.

Here’s the additional code (added onto the already set Alligator.io code above without changing anything in the previous code) that specifies the max width as a smartphone of 40em. Anything at that size width or smaller will display the stacked look.

 @media screen and (max-width: 40em) {
  .container {
    grid-template-areas:
      "head head head head"
      "main main main main"
      "side side side side"
      "footer footer footer footer";
  }
}

a diagram of a web page with a header, main area, sidebar and footer .

Let’s look at another example from Shadeed that adds the media query code for three different types of devices.

Here is the initial code for defining the template areas and the three-column grid:

 .wrapper {
    display: grid;
    grid-template-columns: 1fr 1fr 1fr;
    grid-template-areas:
       "featured item-1 item-1"
       "featured item-2 item-2";
    grid-gap: 1.25rem;
}
 
.item.featured {
  grid-area: featured;
}
 
.item-2 {
  grid-area: item-1;
}
 
.item-3 {
  grid-area: item-2;
}

This is how it looks (with the labels added afterward to demonstrate placement; these wouldn’t show up without additional HTML code):

a grid CSS template showing a featured item 1 and a featured item 2

To make this fully responsive, do not change the code that defines the template areas, but add code for stacked layout and for the three-column layout with “Featured item” in column 1 and then “item 1” in column 2 and “item 2” in column 3.

What Shadeed also does below is take the original code that created the CSS grid template and labels it with a media query.

 /* Stacked Layout */
main {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-template-areas: 
            "featured featured featured" 
            "item-1 item-1 item-1" 
            "item-2 item-2 item-2";
  grid-gap: 1.25rem;
}
 
/* 3-col Layout */
@media (min-width: 600px) {
  main {
    grid-template-areas: 
            "featured item-1 item-2" 
            "featured item-1 item-2";
  }
}
/* Featured Layout */
@media (min-width: 900px) {
  main {
    grid-template-areas: 
            "featured item-1 item-1" 
            "featured item-2 item-2";
  }
}

And here's what that looks like:

an illustration showing three different types of layouts for CSS grids: stacked, 3-col and featured.

Summing Up

CSS grid templates speed up design, which is why there are so many examples of prebuilt templates available. They’re also an invaluable tool for responsive websites.

Because of this — even though in a website builder platform like Duda you can cut and paste elements around without coding them in CSS — you’ll want to understand and master how CSS grid templates work to improve your web design skills.

Duda, refreshed: A more modern way to build and manage sites

By Duda • March 10, 2026

Discover a more intuitive, professional UI with a streamlined sidebar and enhanced top navigation, helping you build faster and with greater confidence.

Why Duda is one of the highest reviewed website builders on G2

By Stephen Alemar • October 23, 2025

Discover why Duda is a top-rated website builder on G2, recognized for usability, easy setup, strong relationships, and excellent results, all backed by real reviews.

Why digital marketing agencies are choosing Duda over Wix Studio and Wordpress

By Ilana Brudo • October 16, 2025

Discover why digital marketing agencies are choosing Duda over Wix Studio and WordPress for speed, reliability, and client experience, and how it helps them scale without operational overhead.

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.