Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Solution
GitHub Logo

Prerender with Dynamic Attributes

Harper lets teams pre-render pages for global speed while keeping prices, inventory, and promos live by storing fast-changing values as lightweight attributes and injecting them at request time. By unifying database, cache, messaging, and runtime in a distributed platform, it removes ISR/API complexity, avoids full-page revalidation, and delivers static-level performance without rewrites or stack changes.
Solution

Prerender with Dynamic Attributes

Harper
at Harper
August 26, 2025
Harper
at Harper
August 26, 2025
Harper
at Harper
August 26, 2025
August 26, 2025
Harper lets teams pre-render pages for global speed while keeping prices, inventory, and promos live by storing fast-changing values as lightweight attributes and injecting them at request time. By unifying database, cache, messaging, and runtime in a distributed platform, it removes ISR/API complexity, avoids full-page revalidation, and delivers static-level performance without rewrites or stack changes.
Harper

In digital commerce, speed drives growth. Faster pages improve user experience, boost conversions, and lift SEO—but dynamic content often gets in the way.

When prices, inventory, or promos are always changing, pre-rendering can seem out of reach. Most tools treat dynamic data as a blocker.

Harper makes it a feature.

The Shortcomings of Traditional Approaches

Most modern web stacks force a choice between speed and flexibility.

Frameworks like Next.js attempt to bridge the gap with features like Incremental Static Regeneration (ISR), but they still rely on external APIs and separate data layers that introduce latency and complexity. Every dynamic update requires cache revalidation, regeneration logic, and additional infrastructure to scale cleanly.

Meanwhile, traditional CDNs offer excellent performance for static assets, but treat caching as an all-or-nothing operation. You can cache the whole page or not at all. That binary model makes serving real-time data messy, brittle, and expensive.

At scale, even small performance penalties compound, adding milliseconds for every round-trip between origin, application, and data layers.


For 95% of users, Harper delivers full page load in under 600 ms.

* Assumes in-region PoPs, pre-rendered HTML with dynamic values computed in ~200 ms server time, HTTP/2+keep-alive, and typical broadband/LTE conditions. First-hit connections and large payloads may be higher.

The Harper Solution

Harper makes pre-rendering viable for dynamic, data-rich experiences. By unifying the database, cache, messaging, and app layer into a single distributed platform, Harper delivers the speed of static rendering with the flexibility of live data, no rewrites required.

How it works:
You pre-render the core layout and content of a page—everything that rarely changes—and cache it globally. The fast-changing elements, like price or inventory, are stored in a lightweight attributes table directly within Harper’s runtime. When a request comes in, those values are injected on the fly with nearly no detectable latency penalty, typically in just 1 or 2 milliseconds.

Unlike ISR or API-bound solutions, Harper eliminates the need to regenerate entire pages or manage complicated revalidation logic. Your frontend doesn’t change. Your stack doesn’t have to move. You just layer Harper in front and start shipping faster experiences.

And because Harper’s architecture is distributed by default, both content and data live closer to every user, delivering consistently fast performance no matter where in the world your customers are.

Conclusion

Pre-rendering doesn’t have to come at the cost of freshness, and real-time data doesn’t have to slow you down.

Harper’s dynamic attribute prerendering unlocks a new model for digital commerce performance: fast, flexible, and fully future-ready. Whether you’re optimizing for search bots or real buyers, the results speak for themselves.

Ready to move faster? Let’s talk.

In digital commerce, speed drives growth. Faster pages improve user experience, boost conversions, and lift SEO—but dynamic content often gets in the way.

When prices, inventory, or promos are always changing, pre-rendering can seem out of reach. Most tools treat dynamic data as a blocker.

Harper makes it a feature.

The Shortcomings of Traditional Approaches

Most modern web stacks force a choice between speed and flexibility.

Frameworks like Next.js attempt to bridge the gap with features like Incremental Static Regeneration (ISR), but they still rely on external APIs and separate data layers that introduce latency and complexity. Every dynamic update requires cache revalidation, regeneration logic, and additional infrastructure to scale cleanly.

Meanwhile, traditional CDNs offer excellent performance for static assets, but treat caching as an all-or-nothing operation. You can cache the whole page or not at all. That binary model makes serving real-time data messy, brittle, and expensive.

At scale, even small performance penalties compound, adding milliseconds for every round-trip between origin, application, and data layers.


For 95% of users, Harper delivers full page load in under 600 ms.

* Assumes in-region PoPs, pre-rendered HTML with dynamic values computed in ~200 ms server time, HTTP/2+keep-alive, and typical broadband/LTE conditions. First-hit connections and large payloads may be higher.

The Harper Solution

Harper makes pre-rendering viable for dynamic, data-rich experiences. By unifying the database, cache, messaging, and app layer into a single distributed platform, Harper delivers the speed of static rendering with the flexibility of live data, no rewrites required.

How it works:
You pre-render the core layout and content of a page—everything that rarely changes—and cache it globally. The fast-changing elements, like price or inventory, are stored in a lightweight attributes table directly within Harper’s runtime. When a request comes in, those values are injected on the fly with nearly no detectable latency penalty, typically in just 1 or 2 milliseconds.

Unlike ISR or API-bound solutions, Harper eliminates the need to regenerate entire pages or manage complicated revalidation logic. Your frontend doesn’t change. Your stack doesn’t have to move. You just layer Harper in front and start shipping faster experiences.

And because Harper’s architecture is distributed by default, both content and data live closer to every user, delivering consistently fast performance no matter where in the world your customers are.

Conclusion

Pre-rendering doesn’t have to come at the cost of freshness, and real-time data doesn’t have to slow you down.

Harper’s dynamic attribute prerendering unlocks a new model for digital commerce performance: fast, flexible, and fully future-ready. Whether you’re optimizing for search bots or real buyers, the results speak for themselves.

Ready to move faster? Let’s talk.

Harper lets teams pre-render pages for global speed while keeping prices, inventory, and promos live by storing fast-changing values as lightweight attributes and injecting them at request time. By unifying database, cache, messaging, and runtime in a distributed platform, it removes ISR/API complexity, avoids full-page revalidation, and delivers static-level performance without rewrites or stack changes.

Download

White arrow pointing right
Harper lets teams pre-render pages for global speed while keeping prices, inventory, and promos live by storing fast-changing values as lightweight attributes and injecting them at request time. By unifying database, cache, messaging, and runtime in a distributed platform, it removes ISR/API complexity, avoids full-page revalidation, and delivers static-level performance without rewrites or stack changes.

Download

White arrow pointing right
Harper lets teams pre-render pages for global speed while keeping prices, inventory, and promos live by storing fast-changing values as lightweight attributes and injecting them at request time. By unifying database, cache, messaging, and runtime in a distributed platform, it removes ISR/API complexity, avoids full-page revalidation, and delivers static-level performance without rewrites or stack changes.

Download

White arrow pointing right

Explore Recent Resources

Blog
GitHub Logo

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Blog
Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Jul 2026
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog
GitHub Logo

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Select*
Blog
AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
A smiling man with a beard and salt-and-pepper hair stands outdoors with arms crossed, wearing a white button-down shirt.
Stephen Goldberg
CEO & Co-Founder
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Jun 2026
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog
GitHub Logo

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Shell
Blog
A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Person with long wavy brown hair wearing a bright pink shirt with a teal trim, smiling outdoors in soft sunlight with blurred trees in the background.
Bailey Dunning
Forward Deployed Engineer
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Jun 2026
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog
GitHub Logo

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
A.I.
Blog
The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Jun 2026
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom