); } function ThemeToggle() { const theme = useContext(ThemeContext); // ... } ``` The nice part is that any component living under that provider can call `useContext` and read the value directly. Here's the catch, though, and it's the reason context has the slightly bruised reputation it carries. Whenever the value in a context changes, every single component consuming that context re-renders. All of them, no exceptions. And before you assume `React.memo` will rescue you here, it won't, which catches a lot of people off guard. The thing about `memo` is that it skips a re-render when a component's *props* haven't changed. But a context consumer isn't reacting to props at all; it's reaching past them and subscribing to the context directly. So when the value's identity changes, every consumer re-renders straight through any `memo` boundary you've placed between them and the provider, as if it weren't there. Which means the moment you do something like this, you've quietly built yourself a performance trap: ```tsx // Don't do this const AppContext = createContext(); function App() { const [user, setUser] = useState(); const [theme, setTheme] = useState(); const [notifications, setNotifications] = useState([]); return ( {/* ... */} ); } ``` Every time `App` re-renders, that `value={{ user, theme, notifications, ... }}` builds a brand-new object with a brand-new identity, even when none of the actual values inside it have changed (That's how JavaScript objects work). React compares the new object to the previous one, sees they have different identities, concludes the context changed, and forces every child in the context to re-render. There are ways out, but each one is a bit of a chore. You can split that one context into several narrow ones, so a change to the notifications context doesn't wake up everyone reading the theme. You can wrap the value object in `useMemo,` so it retains its identity when nothing relevant has changed. You can even separate the state context from the dispatch context, so the components that only ever fire actions don't re-render every time the state moves underneath them. But notice what's happening once you're stacking split contexts and `useMemo` to hand-build selector behavior that context refuses to give you natively. Context was designed to inject values that change slowly, not to act as the backing store for a state that updates many times a second across a wide tree. When you find yourself fighting it that hard, you've outgrown it. ## A global store So you've arrived at the situation that the context couldn't handle. The value changes frequently, plenty of components across the tree each read a different slice of it, and what you really need is for each of those components to re-render only when its own slice changes. You might just need a State Management Library. The one I reach for first these days is Zustand, mostly because it's small. (I have this podcast episode with the author of Zustand, Jotai, and Waku, where we talk in depth on why it's small, [check it out here](https://www.youtube.com/watch?v=ns8ith5cu-U&list=PLeeGnEj5psFIwWJfpCwnedMsFApK6CvRr&index=20)) ```tsx import { create } from 'zustand'; const useCartStore = create((set) => ({ items: [], addItem: (item) => set((state) => ({ items: [...state.items, item] })), clear: () => set({ items: [] }), })); function CartCount() { // Re-renders only when items.length changes, not on every store update const count = useCartStore((state) => state.items.length); return {count}; } function AddButton({ product }) { const addItem = useCartStore((state) => state.addItem); return ; } ``` When `CartCount` subscribes with `(state) => state.items.length`, it's telling Zustand to wake it up only when that specific number changes. And `AddButton` subscribes to `addItem`, which is a function whose identity never changes, so it effectively never re-renders from store updates. The store is just a hook you call. And because it isn't tied to React's render cycle, you can also read it from outside a component entirely with `useCartStore.getState()`, which sounds like a footnote until the first time you need to call some store logic from an event handler or a utility that isn't a component, and it's just there waiting for you. I do want to add one caveat right here. If you write a selector that builds and returns a *new* object or array every time it runs, you are not using Zustand corectly and have the same problem as Global Context. Say you write `useCartStore((s) => s.items.filter(i => i.active))`. That `filter` returns a freshly created array on every call, so it has a new identity each time. Zustand compares it to the previous one by identity, sees two different references, and concludes the value changed, which makes your component re-render on every render, forever. The solution is the hook `useShallow` from `zustand/shallow`, which compares the *contents* instead of the identity. Selectors that return a single primitive value, like `items.length` or a single string field, are fine as they are; it's only those that assemble a new object or array that need the extra help. Now, Zustand isn't the tool you can use. Redux Toolkit (the new Redux library) is still genuinely the right call for a particular kind of application: the large, long-lived one with many engineers touching it, where DevTools time-travel is very useful. (Fun Fact: I also have a podcast episode with Mark Erikson, creator of Redux Toolkit and long-time maintainer of Redux, [check it out here](https://www.youtube.com/watch?v=dbe0wC9Y8bo&list=PLeeGnEj5psFIwWJfpCwnedMsFApK6CvRr&index=3)) And there's a third state management use case you should know about. Sometimes your shared state isn't really one object at all; it's more like a graph of many small, independent values. For that, Jotai (also from Daishi Kato, the creator of Zustand) models states as atoms you compose, and components subscribe at the level of an individual atom, so a change to one atom only ever touches the components reading that specific atom. It's the same flow Zustand gives you, just approached from the bottom up instead of the top down. The rule sitting underneath all three of these is the same: a global store is for a state that is, honestly, actually global. The mistake people make is borrowing the store's ability to reach anywhere as a shortcut for a state that isn't global at all. And the single most common thing stuffed into one of these stores is server data, which has its own dedicated tool, and we will talk about next. ## Server state Here's a thing that took me embarrassingly long to internalize: the single largest pile of what we call "shared state" in most apps doesn't actually belong to the app at all. It belongs to the server, and all your app is really doing is holding a copy. Think about what tends to go into a global store. A user object. A list of orders. The contents of a cart that's really persisted in a database somewhere. So a team drops all of that into their store, and then they have to write a whole machine around it to keep that copy honest, the loading flags, the error flags, the refetch logic, the cache invalidation, every bit of it by hand. The store slowly fills up with data that has a real owner living somewhere else entirely, and every component reading it is reading a snapshot that can be stale the very instant the database changes underneath it. The reason this is so awkward is that server state behaves very differently from client state. It's owned remotely, so you're never the authority on it. It goes stale on its own, without you having to touch it. Someone else can change it while you're sitting there looking at your copy. And there's always that gap in time between asking for it and actually receiving it. A plain `useState` or even a Zustand store has no concept of any of those four things, so when you try to model server data with them, you end up reimplementing all of it, usually badly. This is where TanStack Query comes in, and I wrote a whole gentle introduction to it [you can read here](https://neciudan.dev/a-gentle-introduction-to-tanstack-query). To make it work, you create a `QueryClient` once at the root of your app, and that's the shared cache every hook in the tree reads from. ```tsx import { QueryClient, QueryClientProvider } from '@tanstack/react-query'; const queryClient = new QueryClient(); function App() { return ( ); } ``` With that provider in place, any component anywhere in the tree can read from the same cache like this: ```tsx function UserProfile({ userId }) { const { data: user, isLoading, error } = useQuery({ queryKey: ['user', userId], queryFn: () => fetchUser(userId), }); if (isLoading) return ; if (error) return ; return

{user.name}

; } ``` Take a second to notice everything that *isn't* in there. There's no `useState` holding the data, no `useEffect` kicking off the fetch, no loading boolean you have to flip yourself, no cleanup logic to throw away a stale response that arrived too late. But the part that's easy to miss, and the part that earns this a place in an article about communication, is what happens when more than one component wants the same data. You could have ten components scattered all over the tree, each one calling `useQuery` with that same `['user', userId]` key. Because they're all sharing a single `QueryClient`, only one network request actually fires within the dedupe window, and the rest just read the cache entry that request fills. They all update together the instant that the entry changes. Writes to the server state fit the same picture. A mutation runs the update against the server, then tells the cache which keys are now stale, and every component subscribed to those keys handles its own refetch and re-render from there: ```tsx function AddToCart({ product }) { const queryClient = useQueryClient(); const mutation = useMutation({ mutationFn: (item) => postCartItem(item), onSuccess: () => { // Everything reading ['cart'] is stale now; refetch it queryClient.invalidateQueries({ queryKey: ['cart'] }); }, }); return ( ); } ``` And once your server state lives in a query cache where it actually belongs, you'll usually find your global store shrinks down to almost nothing. So much of what was crammed into it was never client state in the first place; it was server state, and once you remove it, what's left behind is the genuinely client-only, genuinely global stuff, which tends to be a far shorter list than the store you started with. ## URL State A lot of what we call application state isn't really state about the application at all; it's just a description of what the user is looking at right now. The filter is active. The page they're on is in a paginated table. The search query they typed. The tab they selected. Whether a detail panel is open or closed. None of that is really *yours* to hold onto in memory, because it's just a snapshot of the current view. And for that whole category of "what am I currently looking at," the browser has already handed you a global, shareable, persistent store that you can use: the URL. The moment you move that state into the URL, three separate problems quietly solve themselves at once. The view becomes shareable because the link now carries the state, so someone can paste it to a colleague and land on the exact same view, and it survives a refresh because the state was never trapped in memory to begin with. And the back button starts working the way users expect, because each state you set becomes its own entry in the browser's history. The best part is that you get all of this precisely for the kind of state users most expect to be able to bookmark and send around. The raw way to do this is `URLSearchParams`, but it's string-only and genuinely miserable to keep in sync by hand, so in practice I reach for `nuqs`, which makes a search param behave like a typed `useState`: ```tsx import { useQueryState, parseAsInteger } from 'nuqs'; function ProductList() { const [search, setSearch] = useQueryState('q'); const [page, setPage] = useQueryState('page', parseAsInteger.withDefault(1)); // Both now live in the URL: /products?q=shoes&page=2 } ``` I believe this belongs in an article about communication because it connects two components that are far apart. Picture a filter bar on one side of your layout and a results table on the other. With the URL holding the state, they don't need a shared parent, a context, or a store to stay in step with one another. They simply both read and write the same URL parameter. The URL is the shared state, and the router is the broadcast mechanism quietly notifying everyone when it changes, so you've got two distant components staying perfectly coordinated through a channel that also happens to be the address bar at the top of the window. Where do you draw the line on this? The test I use is simple. If the state describes the view and a user would reasonably want to link to it, it belongs in the URL. But if it's an ephemeral interface state that would just be strange to find in a shared link, a half-open dropdown, a hover effect, the unsaved contents of a form draft, then keep it local. ## Event-driven communication Picture two components that have no sensible shared ancestor, no shared URL state, and no shared server resource tying them together. The relationship they have is better described not as "we both need to know this value" but as "when this thing happens over here, that thing should react over there." The example everyone reaches for, because it's such a clean fit, is a toast notification system. Almost anything, almost anywhere in your app, might need to raise a toast, and meanwhile, a single toast viewport sitting somewhere in your layout is responsible for actually displaying them. If you tried to solve that by threading a callback from every possible sender all the way up to some common parent and then back down to the viewport, you'd be building the exact prop-drilling nightmare this whole article has been steering you away from. So your next thought is probably the one you've earned by reading this far: just reach for context, or a global store. The catch is that a toast isn't a value at all. It's a moment. It flares up, it gets shown, and it's gone, and nobody ever needs to sit there reading "the current toast" the way they'd read the current theme or the logged-in user. But context and stores are both built entirely around values that persist and get read, so the second you try to force a fleeting event into one of them, you feel the tool resisting you. With context, you'd have to park the toast in state, push it down through the provider, and watch every consumer re-render each time one popped up. A store gets you a little closer, and plenty of toast libraries are genuinely built on one, but you end up bending a thing designed to hold a readable state around what's really just a queue of one-off messages the viewport drains and forgets. What you actually want is a way to simply broadcast: to say "this happened" out loud and let whoever cares hear it, with nothing kept around afterward. The pattern that genuinely fits this is publish-subscribe, where a publisher announces that something happened without having the faintest idea who's listening, and subscribers react to it without knowing or caring who announced it. And the good news is you don't need to reach for a library to get this. The browser actually ships two event systems you can use, and even if you wanted to build the whole thing from scratch, it's only about a dozen lines. The most direct route uses `EventTarget`, which is the very same machinery that `addEventListener` is built on under the hood, just exposed to you to instantiate directly: ```tsx // A standalone event bus. No dependencies. const bus = new EventTarget(); // Publish from anywhere function notify(message, type = 'info') { bus.dispatchEvent(new CustomEvent('toast', { detail: { message, type } })); } // Subscribe from the viewport function ToastViewport() { const [toasts, setToasts] = useState([]); useEffect(function subscribeToToasts() { function handleToast(event) { setToasts((current) => [...current, event.detail]); } bus.addEventListener('toast', handleToast); return () => bus.removeEventListener('toast', handleToast); }, []); // render toasts } ``` The beauty of it is that `notify('Saved!', 'success')` can be called from a button handler, deep in your API layer, a route guard, or anywhere at all, and it reaches that viewport without a single shared prop running between them. The `detail` field hanging off `CustomEvent` is simply how you smuggle the payload through to the other side. And if you'd rather not lean on DOM types for this, the same idea collapses into a tiny hand-rolled registry, really just a map of event names to sets of callbacks, with `emit`, `on`, and `off` to drive it. That, when you get right down to it, is all that `mitt` (an event-driven library) and the other micro-libraries in this space actually are, and it's worth seeing that you could write the thing yourself in an afternoon: ```tsx function createEmitter() { const listeners = new Map(); return { on(event, fn) { if (!listeners.has(event)) listeners.set(event, new Set()); listeners.get(event).add(fn); return () => listeners.get(event).delete(fn); // unsubscribe }, emit(event, payload) { listeners.get(event)?.forEach((fn) => fn(payload)); }, }; } export const events = createEmitter(); ``` Whichever of the two you go with, the defining quality is that the sender and the receiver share nothing and know nothing whatsoever about each other. That total decoupling is amazing when you think about it, but it's also very problematic. When you are debugging or refactoring you can't trace the flow by reading down the component tree, because there *is* no tree connection to read, so instead you end up grepping for the event name across the codebase and hoping you managed to find every last listener. There's also a timing trap. An event that fires before its subscriber has mounted is simply gone, because there was no one listening when it went out. For toasts, that's a non-issue, since the toast that fires on a click already has a viewport mounted and ready. But for something like a "session expired" event that fires during app boot, the listener might not even exist yet, and you'll need to either buffer those early events or arrange to fire them only once the subscriber is guaranteed to be up. All of which is why I'd treat this as a genuine last resort. It earns its place for the truly cross-cutting, fire-and-forget kind of signal, but the moment you catch yourself using an event bus to share a plain value that two components both need in order to render it, you've used it wrong, because that was lifted state or a store all along. ## How to actually choose When you boil it all down, the decision really comes back to the same two questions every time: how far apart are the two components, and what kind of value is actually moving between them. For a long time, most apps needed only a small handful of these. You'll use props and callbacks constantly, a bit of context for genuinely app-wide stuff like theme and the current user, and TanStack Query for anything that comes from your backend. That combination alone will carry you a remarkably long way, then everything else is a tool you reach for when a specific problem actually calls for it. Nobody's dashboard has ever ground to a halt because someone dared to use props. It's always the other direction: a global store pressed into service for local state, a context made to babysit server data, an event bus smuggling around a value that should have been a simple prop. The reason the big tools are so seductive is precisely that they reach from anywhere, and "reaches from anywhere" turns out to be very hard to tell apart from "I never stopped to think about where this actually belongs." Reach for the closest tool that can actually reach the problem, and only move outward when that tool genuinely stops working. Good luck. ## Reading list - [Fluent React](https://www.amazon.com/Fluent-React-Performant-Intuitive-Applications/dp/1098138716) by Tejas Kumar - [React Application Architecture for Production](https://www.amazon.com/React-Application-Architecture-Production-hands/dp/1836202970) by Alan Alickovic - [Software Architecture: The Hard Parts](https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894) by Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani - [Software Architecture Patterns](https://www.oreilly.com/library/view/software-architecture-patterns/9781098134280/) by Mark Richards ## References - [Sharing State Between Components](https://react.dev/learn/sharing-state-between-components) - React docs, on lifting state up - [Passing Data Deeply with Context](https://react.dev/learn/passing-data-deeply-with-context) - React docs, including the "Before You Use Context" section - [You Might Not Need an Effect](https://react.dev/learn/you-might-not-need-an-effect) - React docs, on derived and colocated state - [Component composition is great btw](https://tkdodo.eu/blog/component-composition-is-great-btw) - TkDodo, on solving drilling with composition - [Zustand](https://github.com/pmndrs/zustand) - minimal store with selector-based subscriptions; see `useShallow` for selectors that return new objects or arrays - [Jotai](https://jotai.org/) - atomic state for graph-shaped client state - [Redux Toolkit](https://redux-toolkit.js.org/) - the standard way to use Redux at scale - [nuqs](https://nuqs.dev/) - type-safe URL search-param state for React - [TanStack Query](https://tanstack.com/query/latest) - server state as a synchronized cache - [EventTarget](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget) - MDN, the built-in event system behind the from-scratch bus - [mitt](https://github.com/developit/mitt) - the micro event-emitter, if you'd rather not hand-roll one - [useImperativeHandle](https://react.dev/reference/react/useImperativeHandle) - React docs, for imperative parent-to-child calls - [ref as a prop](https://react.dev/blog/2024/12/05/react-19#ref-as-a-prop) - React 19 release notes, on dropping `forwardRef` --- ## Upgrading from Astro 3 to Astro 6, with Claude doing most of the work URL: https://neciudan.dev/astro-upgrade-from-3-to-6 Published: 2026-06-11 After three years on Astro 3.0.2, this site was overdue for an upgrade. I knew the project was behind. But I was surprised to find that I am three whole versions behind, with 45 known vulnerabilities in the dependency tree, a deprecated config, and a Tailwind integration the Astro team had stopped maintaining. Migrating was very complicated. This project is much more than a blog: it includes courses, workshops, automated emails, reminders, subscriptions, podcast summaries, ads, and more. Even moving to a single new version was daunting. But when Anthropic released Fable 5, the first in the Claude 5 family, I finally had a chance to put it to the test on a major project. So I pointed it at the upgrade, and three days later, the site runs Astro 6.4.5, builds 44% faster, ships 96–98% less JavaScript on the course pages, and has half as many high- and critical-vulnerability issues as before. Along the way, we only broke the course production once. Oppsie. I'll get to that. But first here is how it went, step by step. ## Why now The honest motivation was realizing that I was preaching modularity in every workshop while my entire app was all over the place. I wanted to move to microfrontends. Before I can get there, I need to turn this site into a shell application (a container that loads independent feature modules). The first real extraction is the security course: its content, pages, and components will move into their own module folder. On Astro 3, that's impossible, because 'content collections' (groups of content files managed by Astro) must live in `src/content/`. The framework decides where your content lives. Astro 5 introduced the Content Layer API, which replaces that restriction with `loader` functions you can point anywhere. So the upgrade became a must-do to achieve modularization. For the first PR, I had a clear goal: upgrade three majors with zero change to URLs, layout, styling, or behavior. Nothing moves, and nothing gets redesigned as tests are added along the way. ## How it started The plan had a big, hard check I would use as a gate (Which Fable recommended adding). Before touching anything, a script captured every HTML file the Astro 3 build produced into a sorted list — 290 routes. After the upgrade, the same command runs again, and the two lists get diffed: if we don't have identical file paths and route slugs, the CI/CD failed. This was the main risk for the migration: that the routes changed and my users would see 404s, or, worse, my SEO would go down. ## What breaks between Astro 3 and 6 If you're sitting on an Astro 3 site, wondering what all the breaking changes are between the 3 versions, and are scared to take a look (like I was), the list is quite small (Congrats, Astro team). Let's go through them: **Legacy content collections are gone.** This is the big one. Astro 6 removed support for schema-only (validation rules) collections entirely—every collection now requires an explicit Content Layer loader (a custom file-reading function). To update, you have to point a file selector called a `glob` loader at the folder where your content already lives. A `glob` loader is a tool that automatically detects files in a specified folder based on a filename pattern. ```ts import { glob } from 'astro/loaders'; const postCollection = defineCollection({ loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/post' }), schema: z.object({ /* unchanged */ }), }); ``` Your files don't move, and your zod schemas don't change. However, the way you access each entry changes: `entry.slug` (the user-friendly page identifier) no longer exists. Instead, it’s now `entry.id`, which is based on the file path (excluding the extension), and `entry.render()` is replaced by a standalone `render(entry)` function imported from astro:content. This site had 32 instances where the `.slug` property (which typically represents a URL-friendly identifier) was read and 39 places where the `getCollection` function was called across four different data collections. Each of these `.slug` property accesses needed to be replaced with `.id` accesses, ensuring that the returned value remains unchanged. If `entry.id` for a nested lesson file resolves to anything other than what `entry.slug` used to be, `getStaticPaths` generates different URLs, and your search rankings evaporate. Thanks to our route diff checker, we caught this early. **`output: 'hybrid'` no longer exists.** Astro 5 changed the hybrid content mode to 'static' by combining it into the output. Now, pages become static (pre-rendered) by default, and you can mark individual routes for server-side rendering (SSR) with export const prerender = false. (SSR means content is generated at request time on the server.) This is mostly a one-line configuration change, followed by checking where prerender is used. **Node 22 is now required.** Astro 6.4.x requires Node.js version `>=22.12.0`. This affects several configurations — for this site, it meant specifying the Node.js version in `netlify.toml` (Netlify deploys), `.nvmrc` (local development), and `engines.node` (Node version for package managers) so local environments, continuous integration (CI), and the deployment runtime all use the same Node.js version. **Your dependencies jump majors with you.** `@astrojs/netlify` went from version 3 to 7 here. The `npx @astrojs/upgrade` tool automatically finds the set of compatible package versions for you, which mostly works—except for one issue. Three packages in this project (`@astrojs/tailwind`, `@astrolib/seo`, `@astrolib/analytics`) cap their peer dependencies at Astro 5, and Netlify runs a strict `npm ci` that refuses to install them. The pragmatic fix was setting `legacy-peer-deps=true` (which tells npm to ignore peer dependency conflicts) in `.npmrc`. The real fix is replacing all three packages. We deferred this so the upgrade stayed purely infrastructural. (But we will fix it later; hopefully, I won't forget.) That's it. We had zero `Astro.glob` uses, the image API didn't complain, and the icon integration survived untouched. ## The migration, in numbers Once the build was successfully completed ("green" means no errors), we measured the impact. Both builds used identical content on the same machine, so the comparison isolates the migration itself. | Metric | Astro 3 | Astro 6 | Change | |---|---|---|---| | Production build (wall clock) | 25 s | 14 s | **−44%** | | Astro server-build phase | 23.4 s | 9.9 s | **−58%** | | Client JS (total) | 849 KB | 746 KB | **−12%** | | Known vulnerabilities | 45 | 26 | **−42%** | | — high + critical | 20 | 10 | **−50%** | | HTML pages generated | 290 | 290 | identical | The biggest pleasant surprise was that my build time was cut in half. Nothing about this site changed — same content, same pages — and the Astro server build phase dropped from 23.4~ seconds to 12~ seconds (I tried it 10 times and took the average). Those gains come from improvements in the Astro compiler and the Vite tool, simply by upgrading. But External CSS grew by 116 KB because Astro changed how it decides what to inline and what to externalize between versions 3 and 6. (Honestly, this was a lot, and I flagged it for future improvements.) The net payload (JS + CSS) moved 1.2%, and the rendered pages are visually identical. The route diff came back empty: 290 routes in, 290 routes out with the same slugs and content. Then, after a quick LGTM review, I merged the PR and now the interesting part could start. ## Auditing three major features Upgrading a software framework and then not using any of its new features for three years would be like buying an F1 car and keeping it in the garage. What did Astro 4, 5, and 6 add that this site should use to improve it? Fable went through the release notes feature by feature and produced a ranked table — what each feature does, the concrete opportunity in this codebase, the expected benefit, the effort, and the risk. Here is the trimmed-down version of it: | Feature | What it does | Opportunity here | Expected benefit | Effort | Risk | |---|---|---|---|---|---| | **Responsive Images** | Native `srcset`/`sizes`, `priority` prop for LCP | Replace 320+ lines of manual srcset logic in our custom `Image.astro` | Smaller images, correct `sizes`, ~320 lines deleted | S | Low | | **``** (View Transitions) | SPA-style navigation with animations | Blog index → post and course module nav | Instant perceived navigation | S | Medium — inline scripts need `astro:page-load` guards | | **Prefetch** | Hover/viewport prefetching for links | Blog cards + course module links | Near-zero latency on common paths | S | Low | | **`astro:env`** | Typed env schema: client/server, public/secret | 15+ untyped `import.meta.env` reads across 6 files | Build-time validation; secrets can't ship to the client | M | Low | | **`astro:actions`** | Type-safe server actions with Zod validation | The subscribe API route + the form-handling Netlify functions | One typed contract instead of fetch boilerplate | L | Medium — Stripe/external functions keep their own runtime | | **Server Islands** (`server:defer`) | CDN-cached static shell + deferred server-rendered component | Course dashboard runs auth 100% client-side, shipping 166 KB of Supabase to every visitor | Auth moves server-side; Supabase ships only when needed | L | High — needs server-readable (cookie) sessions | | **Fonts API** | Fonts declared in config; auto preload + optimized fallbacks | Replace `@fontsource-variable/inter`; font preload is currently absent | LCP/CLS win on every page | S | Low | | **SVG Components** | Import `.svg` files as components | Little — `astro-icon` already covers icons | Cleaner markup at best | S | Low | | **`

My post

{product.name}

Hello from the server