Best way to handle price range filtering in Hugo for large data sets

support
1

I am using Hugo and each product is stored in a content .md file.
Each product has a price field in front matter.

Example:

price: 750000

What I need

On the listing page, I want to filter products by price range, like:

  • 0 – 5 lakh
  • 5 – 10 lakh
  • 10 – 20 lakh
  • 20 lakh+

Current approach

Right now, I am doing this manually:

  • I load all products by default

  • I created price range filters in the UI

  • When a user clicks a price range:

    • I hide the default list
    • I show only the filtered products using JS

Problem

This approach works fine when the data is small.

But when we have 10,000+ products, it becomes slow because:

  • All products are rendered initially
  • Filtering happens after page load
  • Large DOM + JS filtering hurts performance

Question

What is the recommended Hugo way to handle price filtering for large datasets filtering ?

2

You’d have to create static pages for every range of prices

3

or create hidden static sections and switch their display

4

Thank you for the reply, that makes sense

Could you please guide me through the steps for implementing this using pure Hugo (build-time only)?

I already have a JavaScript-based filtering version working, but I want to understand the Hugo-only approach, such as:

  • creating static pages for each price range, or
  • using static sections/layouts that render filtered content at build time

Even a high-level step-by-step explanation would be very helpful.

Thanks again for your help.

5

before we dig in details let me ask where this +10000 come from? guess you dont write them manually.

if that is automated can you plug in the range calculatien in the generation?

6

We do not write those values manually.

The +10000 comes from automated data generation, typically done using a script (for example, Python). All calculations are completed before Hugo runs.

Hugo templates do not generate or calculate ranges. They only read values that already exist in the Markdown frontmatter.

In this setup, all car data is stored as individual Markdown files inside the content/cars/ directory, for example:

content/cars/car-1.md
content/cars/car-2.md
...
content/cars/car-10000.md

Each of these Markdown files is generated automatically and contains precomputed fields (such as price or price ranges). Hugo simply loads these files and renders pages based on the existing data without performing any additional calculations.

7

and your script generates:

so your range definition can be calculated before (in the scripts) something like priceclass: one or do you need the flexibility to define the ranges at generation (hugo)time? or are the price ranges the base for your selection.

one more. you mentioned 4 ranges which result in 2500 items per page. quite a lot. any plan how to handle that?

8

1. Do we calculate price ranges in scripts (priceClass) or define them at Hugo time?

We do not calculate price ranges in JavaScript (like priceClass: 1, 2, 3…).

Instead, price ranges themselves are the base of selection, and they are defined at Hugo generation time.

Why this approach?

  • Price ranges are fixed business rules:

    • 0–5 lakh
    • 5–10 lakh
    • 10–20 lakh
    • 20 lakh+

  • They rarely change

  • They are meaningful URLs and pages (good for SEO)

So instead of:

“Load all cars → calculate range in JS → filter in browser”

We do:

“Define price ranges → build separate pages → load only what is needed”

2. How price range handling actually works

Step 1: Price range folders (build-time)

We create one folder per price range:

content/price/
├── 0-5-lakh/_index.md
├── 5-10-lakh/_index.md
├── 10-20-lakh/_index.md
└── 20-lakh-plus/_index.md

Each folder represents one static price-range page.

Step 2: Hugo filters cars for that range

In layouts/price/list.html:

  • Hugo checks the current price range
  • Filters cars at build time
  • Outputs only cars that belong to that range

No JavaScript filtering is needed on these pages.

3. Why not generate ranges in scripts?

If we generated priceClass in JS:

  • All cars still need to be loaded first
  • Filtering happens after page load
  • Performance and payload size remain poor

Using Hugo build-time filtering means:

  • Smaller HTML
  • Faster load
  • Cleaner logic
  • Better SEO

So flexibility is intentionally sacrificed for performance and clarity.

4. About “2500 items per page” — what’s the plan?

Current state (honest answer)

Right now:

  • We do not have pagination
  • A price range page can have many cars

Why this is still acceptable (for now)

Earlier:

  • One page loaded all cars across all ranges
  • JS just hid and showed them

Now:

  • Only one price range loads at a time
  • Users never download unrelated data

So even 2500 items:

  • Is already a big improvement
  • Is limited to a single, intentional page

5. Future handling (not implemented yet)

Later we can add:

  • Pagination
  • Lazy loading
  • Infinite scroll

But the foundation is correct:

  • Price ranges defined at build time
  • Data split into static pages
  • No client-side heavy filtering

Short final answer

Price ranges are not calculated dynamically in scripts. They are defined at Hugo build time and are the base for selection. Each price range has its own static page, and Hugo filters cars during generation. This avoids loading all cars in the browser and fixes the performance issues we had earlier. Large result sets are currently accepted per page, but only within a single price range, and pagination can be added later if needed.

9

read that a few times and am confused…

combined with all the above - I have no idea if there’s anything open ???

10

content/price/
├── 0-5-lakh/_index.md
├── 5-10-lakh/_index.md
├── 10-20-lakh/_index.md
└── 20-lakh-plus/_index.md

The content/price/ directory is structured as 0-5-lakh/_index.md, 5-10-lakh/_index.md, 10-20-lakh/_index.md, and 20-lakh-plus/_index.md, with each folder representing a specific price range. Hugo treats each _index.md as a section page and generates a separate static page for every price range at build time using a shared template located at layouts/price/list.html. Car data is filtered by price range entirely during the build process based on the front matter defined in each _index.md, eliminating the need for any client-side JavaScript filtering. This results in clean, maintainable code, faster page loads, and improved SEO through fully pre-rendered static pages for each price range.

11

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.