Tommy Fredrik Fjordland Next JS Design System

TINE, a prominent Norwegian dairy company, has maintained a long-standing relationship with Enonic as its content platform. The company’s digital portfolio includes major websites such as TINE.no, which first went live in 2005.

Recently, the team responsible for Fjordland.no—partly owned by TINE (51%) and fully managed by its infrastructure—undertook a complete rebuild of the Fjordland brand’s online presence.

Previously, Fjordland’s website faced several challenges: outdated design, slow load times, limited mobile responsiveness, and fragmented content spread across multiple sub-brands and separate platforms.

The new objective was to unify these brands into one cohesive site, improve performance, create a more intuitive content editing workflow, and integrate a newly developed design system known as KREM.

Recently, TINE held a presentation at Enonic. They showed how the integration of Enonic XP, Next.js, and the KREM design system supported these goals and, in the process, created a remarkably fast and editor-friendly website.

See the presentation here:

Fjordland, Next js, and Design System

Transitioning from Traditional CMS to a Headless Approach

Before the rebuild, Fjordland.no used a more traditional CMS approach, where front-end and back-end were tightly coupled. This setup, relying on templating engines like Thymeleaf and Freemarker, made it difficult to incorporate modern React-based design systems.

The development team set forth several key priorities for the new site:

  • Modern Developer Experience: The ability to utilize a contemporary front-end framework and design system.
  • Seamless Design Integration: Easy integration of the React-based KREM design system.
  • Editor-Friendliness: A simplified content editing process.
  • High Performance: Rapid load times and the ability to handle large traffic surges.

After evaluating options, the chosen solution was a headless architecture using Enonic XP as a back-end content source, Guillotine as a GraphQL API layer, and Next.js for front-end rendering.

The Chosen Stack: Enonic XP, Guillotine, and Next.js

The final architecture separates concerns neatly:

  • Enonic XP: Maintains content storage and editorial interfaces, providing a flexible, headless CMS environment.
  • Guillotine (GraphQL API): Serves as a data layer, allowing the front-end to query only the necessary information and customize responses.
  • Next.js (Front-End): Delivers the presentation layer, supports static site generation (SSG), and integrates naturally with React-based components from the KREM design system.

Why Opt for Next.js?

Next.js offers multiple rendering strategies—client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG). For the Fjordland project, SSG was selected to ensure swift load times.

During the build process, Next.js generates static HTML files for all requested pages. When users visit the site, content is served instantly from these pre-built pages, minimizing load times and improving user experience.

Additionally, as a React framework, Next.js simplifies integration with KREM, the design system built on React components. This setup reduces complexity, ensures maintainable code, and provides a modern development environment.

See also: Build a Fast and Modern Site with Next.js and Headless CMS »

Dynamic Content with Static Generation

All content is fetched through a GraphQL query against Guillotine. Next.js iterates over the content hierarchy at build time and pre-renders static paths for each piece of content. On the initial user request, the page hydrates with the necessary JavaScript, and subsequent visitors receive instant, cached responses.

A block-based approach manages the site’s dynamic content. Each piece of content—such as a hero image, a text block, or a product listing—maps to a specific React component. A serialization function selects the appropriate component type and composes the final page dynamically.

For image optimization, the Next.js <Image> component is used. In preview mode, when internal Next.js image URLs are not accessible to the editorial interface, the system falls back to standard HTML images, ensuring the editor’s preview remains representative.

Performance Gains

These combined measures led to substantial performance improvements. The old Fjordland site struggled with performance metrics; the new implementation now achieves top scores in Lighthouse assessments.

Large images load in about a quarter of a second, and layout shifts are eliminated. Accessibility, SEO, and best practices all show marked improvements, delivering a smoother and more reliable user experience.

Read the Fjordland case study »

Enhancing the Editorial Experience

The editorial workflow was intentionally streamlined. Instead of burdening editors with complex layout controls and configurations, the system offloads layout logic to the front-end. Editors simply select content blocks and enter the relevant information.

The preview feature in Enonic XP, integrated with Next.js, provides a dynamic, draft-mode view of the site. This allows editors to see changes as they will appear to end-users, without manual redeployment.

When edits are published, incremental static regeneration triggers a cache purge and content revalidation on the Next.js side. The result is nearly instant updates to the live site without the need for time-consuming rebuilds.

Challenges and Key Lessons

Several insights emerged during development:

  1. Build Times: Initial full builds approached 25 minutes. After optimization, build times dropped to around 12 minutes. Node modules installation, packaging, and content fetching remain non-trivial tasks.

  2. Complex Logging and Debugging: Running both XP and Next.js servers can complicate issue tracking. Logs must be examined across multiple systems.

  3. Hosting Considerations: Hosting Next.js in Azure Cloud introduced additional complexity compared to more conventional setups.

  4. Unexpected Traffic Spikes: During a Snapchat “takeover” ad campaign that directed massive traffic to Fjordland.no, request rates soared to 80,000 per minute. Originally, a single-thread Node.js process handled requests. Quickly adopting a process manager and scaling horizontally ensured stable performance even under unexpected load surges.

Looking Ahead

The current Next.js and Enonic XP integration demonstrates impressive stability and performance. Ongoing development by the Enonic team promises further improvements—such as newer React and Next.js versions with integrated image handling—that may simplify the process even more.

See also: Why Choose Enonic's Headless CMS When Building a Next.js Website »

Conclusion

The Fjordland.no rebuild exemplifies how a headless approach, combined with a modern front-end framework and a dedicated design system, can yield significant gains in performance, maintainability, and editorial ease-of-use.

The resulting site achieves rapid load times, dynamic content management, and a frictionless editorial workflow. For organizations evaluating a similar transition, this case study highlights the benefits and lessons learned when embracing Next.js, Enonic XP, and a headless, component-driven architecture.

Guide to Composable CMS

Related blog posts

Get some more insights 🤓


Get started with Enonic! 🚀