Lukas
February 11, 2025, 7:30am
1
HI,
we have noticed that pages that are coming to form builder.io are loading much longer than if we put static HTML. Also, the page seams to re-render on the client side.
Here is the Link to the Page: R Big Bags Abholung / Entsorgung beauftragen – Berlin Recycling Shop
This is the spped index result: https://pagespeed.web.dev/analysis/https-shop-berlin-recycling-de-pages-big-bags-abholung-entsorgung-beauftragen/e4pq1ffczt?form_factor=desktop
Builder content link
Builder.io: Visual Development Platform
Builder public api key
da92e0c53398459689b527346fc360a5
What are you trying to accomplish
The Page is re-rendering on the clientside causing a page speed increase.
Code stack you are integrating Builder with
NextJS
Reproducible code example
import { builder } from '@builder.io/sdk';
import { notFound } from 'next/navigation';
import { builderInit } from '@/lib/builder-io/builder-init';
import { RenderBuilderContent } from '@/lib/builder-io/render-builder-content';
// Initialize Builder.io
builderInit();
interface PageProps {
params: {
path?: string[];
};
}
export default async function Page({ params }: PageProps) {
if (!params?.path?.length) return notFound();
const urlPath = `/pages/${params.path.join('/')}`;
try {
const builderPage = await builder
.get('page', {
options: { includeRefs: true, noTraverse: false },
userAttributes: { urlPath },
prerender: false,
cachebust: false,
cache: true
})
.toPromise();
if (builderPage) {
return <RenderBuilderContent model="page" content={builderPage} />;
}
return notFound();
} catch (error) {
console.error('Error fetching Builder.io content:', error);
return notFound();
}
}
We also wrap our content in a custom component called global-container. Maybe the custom component is the problem…
Why Your Next.js Page is Loading Slowly (Builder.io + No Caching)
If you inspect the response headers for your page using Chrome DevTools, you’ll likely see:
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
This tells browsers and CDNs to:
Never store a cached version
Always re-fetch from the origin server
Prevent any intermediate cache (e.g., Vercel’s Edge, Cloudflare, browser memory)
This is a performance killer — especially for pages built with a CMS like Builder.io that serve the same content to all users.
What You Should Use Instead (for Static or Cached Pages)
If your page content is the same for all users (like most CMS-driven pages), you can safely cache it using:
Cache-Control: public, s-maxage=60, stale-while-revalidate=300
Directive
What it does
public
Allows CDN and browser to cache it
s-maxage=60
CDN (e.g., Vercel, Cloudflare) caches the response for 60 seconds
stale-while-revalidate=300
Serves stale content while fetching a fresh version in the background (non-blocking)
This drastically improves TTFB (Time to First Byte) and perceived performance.
Current Bottlenecks in Your Code
1. No Static Generation or ISR (Incremental Static Regeneration)
Your page uses:
export default async function Page() { ... }
This means it’s server-rendered on every request , with no caching. So:
Every request triggers a cold fetch to Builder.io
The server generates HTML from scratch
Result: higher latency and slower load
2. Builder SDK is set to prerender: false
builder.get('page', {
options: {
prerender: false
}
})
This disables Builder.io ’s internal content prefetching and caching mechanisms, which could otherwise reduce response time.
Recommendations
Switch to Static Generation or ISR
If you’re using the App Router, use revalidate = 60
at the route level:
export const revalidate = 60; // Regenerate in the background every 60s
Update your Cache-Control headers
If self-hosting, set response headers manually. If using Vercel, it will infer them from your ISR settings.
Remove prerender: false
from the Builder SDK options
This allows Builder to optimize content delivery.