Aussagekräftige loading.tsx-Dateien und Skeletons erstellen
Erstellen Sie routenbezogene Ladezustände und Skeleton-Platzhalter, die dem endgültigen Layout entsprechen und Verschiebungen vermeiden.
Aussagekräftige loading.tsx-Dateien und Skeletons erstellen ist eine kostenlose Next.js 15 Fullstack (App Router + Server Actions)-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Next.js 15 Fullstack (App Router + Server Actions)-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Next.js 15 Fullstack (App Router + Server Actions)-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Why loading.tsx Exists
In the App Router, a loading.tsx file is special: Next.js automatically wraps your route segment's page.tsx in a React <Suspense> boundary and shows loading.tsx as the fallback while the server component streams.
- You get an instant loading state with zero manual Suspense wiring.
- It only triggers on the server-render of that segment, not on every client interaction.
- The fallback is shown immediately while the page's async data resolves.
This lesson is about making that fallback meaningful so the user perceives speed and the layout does not jump.
The File Convention
Drop a loading.tsx next to your page.tsx in any route segment. Its default export is rendered as the Suspense fallback for that segment and everything below it.
- It is a normal React component — it can be a Server Component (the default) since it renders only static markup.
- No props are passed to it; it must be self-contained.
- Keep it lightweight so it ships and paints fast.
// app/dashboard/loading.tsx
export default function Loading() {
return (
<div className="dashboard-grid" aria-busy="true">
<DashboardSkeleton />
</div>
);
}The Real Goal: Avoid Layout Shift
A bad loading state replaces your page with a centered spinner, then snaps to a totally different layout when data arrives. That visual jump hurts perceived performance and Cumulative Layout Shift (CLS).
A good skeleton mirrors the final layout:
- Same number of cards, rows, and columns.
- Same approximate widths and heights as the real content.
- Same spacing and grid structure.
When real data swaps in, nothing moves — only the gray placeholders fill with content.
A Reusable Skeleton Primitive
Start with one tiny building block: a Skeleton box that renders a gray, rounded rectangle. You compose everything else from it.
- Accept
classNameso callers control width, height, and shape. - Add an
animate-pulsestyle (Tailwind) or a CSS shimmer for the loading feel. - Mark it
aria-hidden— it is decorative, not real content.
// components/skeleton.tsx
export function Skeleton({ className = '' }: { className?: string }) {
return (
<div
aria-hidden="true"
className={`animate-pulse rounded-md bg-gray-200 ${className}`}
/>
);
}Matching the Final Layout
Build the skeleton by copying the structure of the real component, then replacing text and images with Skeleton boxes sized to match.
- An avatar becomes a circle:
h-10 w-10 rounded-full. - A title line becomes a wide bar; a subtitle becomes a shorter, thinner bar.
- Use the same container classes (padding, gap, border) as the real card.
// components/user-card-skeleton.tsx
import { Skeleton } from './skeleton';
export function UserCardSkeleton() {
return (
<div className="flex items-center gap-4 rounded-lg border p-4">
<Skeleton className="h-10 w-10 rounded-full" />
<div className="flex-1 space-y-2">
<Skeleton className="h-4 w-1/3" />
<Skeleton className="h-3 w-1/2" />
</div>
</div>
);
}Lists: Repeat the Row Skeleton
For lists and tables, render a fixed count of row skeletons — enough to fill the typical viewport so the page looks complete.
- Reuse the single-row skeleton inside an array.
- Pick a count that roughly matches your usual page size (e.g. 6–8 rows).
- Keep the same
gapand wrapper as the real list to preserve spacing.
// components/user-list-skeleton.tsx
import { UserCardSkeleton } from './user-card-skeleton';
export function UserListSkeleton({ rows = 6 }: { rows?: number }) {
return (
<div className="space-y-3">
{Array.from({ length: rows }).map((_, i) => (
<UserCardSkeleton key={i} />
))}
</div>
);
}Wiring the Skeleton into loading.tsx
Now loading.tsx just composes your skeleton components inside the same outer layout as the page. The header that is static (not data-dependent) can be rendered for real even in the loading state.
- Render the real, instant parts (page title, tabs).
- Swap only the data-bound regions for skeletons.
- This gives a page that feels half-loaded already.
// app/dashboard/users/loading.tsx
import { UserListSkeleton } from '@/components/user-list-skeleton';
export default function Loading() {
return (
<section className="mx-auto max-w-2xl p-6">
<h1 className="mb-4 text-2xl font-bold">Users</h1>
<UserListSkeleton rows={6} />
</section>
);
}loading.tsx vs Component-Level Suspense
loading.tsx covers the whole segment — if any data on the page is slow, the entire fallback shows. Sometimes you want finer control so fast content paints first.
- Use
loading.tsxfor the segment-wide first paint. - Wrap individual slow components in
<Suspense>with their own skeleton fallback to stream them independently. - Combine both: a light segment skeleton, plus granular Suspense for the slowest widget.
// app/dashboard/page.tsx
import { Suspense } from 'react';
import { RevenueChart } from './revenue-chart';
import { ChartSkeleton } from './chart-skeleton';
export default function Page() {
return (
<main className="p-6">
<h1 className="text-2xl font-bold">Overview</h1>
{/* Static + fast content paints immediately */}
<Suspense fallback={<ChartSkeleton />}>
{/* Slow async server component streams in later */}
<RevenueChart />
</Suspense>
</main>
);
}Pure Function for Skeleton Counts
How many skeleton rows should you show? A small helper keeps it consistent and clamps to a sane range so you never render an absurd number of placeholders.
This logic is plain TypeScript — no framework involved — so you can unit-test it in isolation.
function skeletonRowCount(pageSize: number, viewportRows = 8): number {
if (!Number.isFinite(pageSize) || pageSize <= 0) return viewportRows;
return Math.min(pageSize, viewportRows);
}
console.log(skeletonRowCount(20)); // 8 (clamped to viewport)
console.log(skeletonRowCount(3)); // 3 (fewer items than viewport)
console.log(skeletonRowCount(0)); // 8 (fallback default)
console.log(skeletonRowCount(-5)); // 8 (guards invalid input)Accessibility & Reduced Motion
Skeletons are decorative, but they still affect assistive tech and motion-sensitive users.
- Mark the loading region with
aria-busy="true"and individual placeholders witharia-hidden="true". - Provide a visually-hidden status like
<span className="sr-only">Loading users</span>for screen readers. - Respect
prefers-reduced-motionso the pulse animation does not run for users who opt out.
/* globals.css */
@media (prefers-reduced-motion: reduce) {
.animate-pulse {
animation: none;
}
}Common Pitfalls
Avoid these mistakes that defeat the purpose of a skeleton:
- Spinner-only fallback: gives no layout cue and guarantees a shift when content arrives.
- Mismatched sizes: if the skeleton card is 60px tall but the real card is 96px, the page still jumps.
- Forgetting the wrapper: different padding/grid between skeleton and page shifts everything.
- Skeleton over fast data: if a segment loads in <100ms, the flash of skeleton can feel worse — consider component-level Suspense for only the slow parts.
Quick Check
Test your understanding of route-level loading states and skeletons.
Recap
You learned how to craft meaningful loading states in the App Router:
loading.tsxis an automatic Suspense fallback for its route segment.- Build skeletons from a small
Skeletonprimitive and compose them to mirror the final layout. - Match wrappers, counts, and dimensions to avoid layout shift (CLS).
- Render instant static parts (titles, tabs) for real; skeleton only the data-bound regions.
- Use
loading.tsxfor segment-wide first paint and component-level<Suspense>to stream slow widgets independently. - Handle accessibility with
aria-busy,aria-hidden, ansr-onlystatus, andprefers-reduced-motion.
Lerne TypeScript mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 22
- Lektionen
- 88
Häufig gestellte Fragen
Ist die Lektion „Aussagekräftige loading.tsx-Dateien und Skeletons erstellen“ kostenlos?
Ja — der vollständige Text von „Aussagekräftige loading.tsx-Dateien und Skeletons erstellen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Next.js 15 Fullstack (App Router + Server Actions)-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Next.js 15 Fullstack (App Router + Server Actions)-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Aussagekräftige loading.tsx-Dateien und Skeletons erstellen“?
Erstellen Sie routenbezogene Ladezustände und Skeleton-Platzhalter, die dem endgültigen Layout entsprechen und Verschiebungen vermeiden. Du übst Next.js 15 Fullstack (App Router + Server Actions) mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Next.js 15 Fullstack (App Router + Server Actions) zu starten?
Keine Vorkenntnisse erforderlich. Next.js 15 Fullstack (App Router + Server Actions) auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Aussagekräftige loading.tsx-Dateien und Skeletons erstellen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Next.js 15 Fullstack (App Router + Server Actions)-Lektion Code schreiben und ausführen?
Ja. Jede Next.js 15 Fullstack (App Router + Server Actions)-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Suspense-Grenzen und Streaming auf Komponentenebene
- Aussagekräftige loading.tsx-Dateien und Skeletons erstellen
- Partielles Prerendering: statische Hülle, dynamische Lücken
- Stolperfallen beim Streaming: Layout Shift und Waterfalls