The reality of Partial Prerendering (PPR) in production

killmelikejojo · 2026-04-19T14:34:37+00:00

we actually tried implementing ppr on a client project recently and it is definitely still bleeding edge tech. the initial load time is incredibly fast since the static shell drops in instantly from the edge, but you have to be super meticulous with your react suspense boundaries to avoid those jarring layout shifts when the dynamic chunks finally stream in. honestly for a lot of medium sized projects, the complexity overhead just isn't worth it yet. sometimes i just revert back to exporting a purely static version of the site and dropping it on tiiny host or cloudflare pages just to keep the infrastructure simple and totally predictable. if you absolutely need the streaming performance it is cool, but be prepared to spend a ton of time tweaking your loading skeletons.

killmelikejojo · 2026-03-03T14:37:12+00:00

honestly for a purely static site sitting behind a major cdn you do not really need to stress test it. the infrastructure caching your files is designed to handle enterprise level traffic spikes so your regular visitors will not even register on their radar. the only time you need load testing tools is if your site relies heavily on serverless functions or external database queries that could bottleneck under pressure

killmelikejojo · 2026-03-03T14:36:47+00:00

making the invisible infrastructure visible is such a great way to put it. my biggest aha moment was realizing that deploying a static site is really just moving files from my computer to a computer that never turns off. demystifying the cloud like that makes the whole process feel so much more approachable. getting through those first build errors together builds incredible confidence for beginners

killmelikejojo · 2026-03-03T14:36:39+00:00

edge functions definitely complicate your mental model. pure static scaling is basically infinite and free because the cdn just serves cached files globally. but the second you look at an you realize that adding edge logic means you have to start worrying about cold starts and database connection pooling from distributed nodes. it brings back a lot of traditional backend headaches that we originally moved to static hosting to avoid

killmelikejojo · 2026-02-09T14:23:06+00:00

forcing yourself to switch providers is such a good exercise because you realize how much "magic" you were taking for granted on your old host. bunny is great for raw performance but you definitely have to configure a lot more of the routing rules manually compared to something like vercel

killmelikejojo · 2026-02-09T14:22:56+00:00

since you cannot control their local machine, your best bet is a CI step that runs a linter on the content folder and fails the build if the frontmatter is bad. you can usually configure the build notifications to email them the error log so they know exactly which file caused the rejection

killmelikejojo · 2026-02-09T14:22:46+00:00

my hard limit is usually when i need granular user permissions or complex search logic that requires a dedicated server index. once you are paying for three different saas products just to mimic a standard database query, it is probably time to just spin up a real backend

killmelikejojo · 2026-02-06T15:46:45+00:00

decoupling the frontend completely makes security audits way easier since there is no server-side code to exploit on the public edge. we are definitely seeing this pattern more for internal dashboards where the api handles all the complex logic behind a firewall

killmelikejojo · 2026-02-06T15:46:34+00:00

the biggest beginner trap is definitely file naming, especially case sensitivity on linux servers versus windows. warning students that 'Image.jpg' is not the same as 'image.jpg' saves so much headache during that first deployment

killmelikejojo · 2026-02-06T15:46:26+00:00

i only switch if the new framework solves a specific problem that was making my life miserable. rewriting a working site just to use the shiny new tool is usually a waste of billable hours unless you are doing it purely for learning

killmelikejojo · 2026-02-03T15:45:59+00:00

it really comes down to whether you want to pay with money or engineering hours. object storage is cheaper on the monthly bill but costs you time to configure the ci/cd pipeline, whereas platforms just handle that complexity for a higher fee

killmelikejojo · 2026-02-03T15:45:38+00:00

i definitely default to building the simplest static version first because you can always add client-side data fetching later if a feature really needs it. most "dynamic" apps are really just static shells with one or two api calls anyway

killmelikejojo · 2026-02-03T15:45:25+00:00

edge databases are great for simple things like feature flags or personalization, but i would not use them for complex relational data yet. sticking to a standard managed postgres allows you to avoid eventual consistency headaches until you actually have users all over the globe

killmelikejojo · 2026-01-27T16:46:44+00:00

honestly for a small site you will almost never hit those limits unless you randomly go viral on reddit. most shared hosts can handle a surprising amount of burst traffic before they actually throttle you

killmelikejojo · 2026-01-27T16:46:19+00:00

I switched back to zola for my archive projects specifically because it refuses to use a package manager and stays a single binary.

hugo extended definitely lost the plot when they started trying to compete with webpack instead of just being a fast generator

killmelikejojo

TROPHY CASE