Why Astro excels at performance - Visual Breakdown

Concept Flow - Why Astro excels at performance

Write Astro Component

↓

Build Time: Render to Static HTML

↓

Send Minimal JS to Browser

↓

Browser Loads Fast

↓

User Interacts with Hydrated Components

↓

Fast Page Load and Interaction

Astro builds pages mostly at build time, sending minimal JavaScript to the browser, which makes pages load and run faster.

Execution Sample

Astro

<script>
  export let name;
</script>
<h1>Hello {name}!</h1>

This Astro component renders a greeting as static HTML at build time, sending no extra JavaScript to the browser.

Execution Table

Step	Action	Result	Effect on Performance
1	Write Astro component with props	Component ready for build	No impact yet
2	Build process renders component to static HTML	<h1>Hello User!</h1>	No runtime JS needed, faster load
3	Send HTML to browser with minimal JS	Lightweight page delivered	Reduces download size
4	Browser renders HTML immediately	Page visible quickly	Improves perceived speed
5	Hydrate interactive parts only if needed	JS runs only where required	Saves CPU and memory
6	User interacts with page	Smooth experience	Fast response due to minimal JS
7	No unnecessary JS loaded	Less blocking scripts	Better performance overall

💡 All steps optimize to reduce JavaScript and improve load speed, ending with a fast, interactive page.

Variable Tracker

Variable	Start	After Build	After Send	After Hydration	Final
HTML Content	Component code	<h1>Hello User!</h1>	<h1>Hello User!</h1>	<h1>Hello User!</h1>	<h1>Hello User!</h1>
JavaScript Sent	Full component JS	None or minimal	Minimal JS for interactivity	Hydrate only interactive parts	Minimal JS loaded
Page Load Time	N/A	Fast	Faster	Fastest	Fastest
User Interaction Delay	N/A	N/A	N/A	Minimal delay	Minimal delay

Key Moments - 3 Insights

Why does Astro send less JavaScript to the browser?

Because Astro renders most content to static HTML at build time (see execution_table step 2), so the browser doesn't need to run extra JavaScript to show the page.

How does hydrating only interactive parts improve performance?

Hydrating only the parts that need JavaScript (execution_table step 5) means less code runs in the browser, saving CPU and memory, making the page faster.

Why is the page visible quickly after sending HTML?

Because the browser can render static HTML immediately without waiting for JavaScript to load or run (execution_table step 4), improving perceived speed.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the component rendered to static HTML?

A Step 4

B Step 2

C Step 5

D Step 3

💡 Hint

Check the 'Action' column for 'Build process renders component to static HTML'

According to the variable tracker, what happens to the JavaScript sent after build?

A Minimal JavaScript for interactivity is sent

B No JavaScript is sent at all

C Full component JS is sent

D JavaScript size increases

💡 Hint

Look at the 'JavaScript Sent' row after 'After Build' and 'After Send'

If Astro hydrated the entire page instead of only interactive parts, how would the performance change?

A Page load time would improve

B Page load time would stay the same

C Page load time would get slower

D JavaScript size would decrease

💡 Hint

Refer to key moment about hydrating only interactive parts and its effect on CPU and memory

Concept Snapshot

Astro builds pages mostly at build time,
renders static HTML,
sends minimal JavaScript only for interactivity,
loads pages fast,
and hydrates only needed parts,
resulting in excellent performance.

Full Transcript

Astro works by rendering components to static HTML during the build process. This means the browser receives mostly plain HTML, which it can display immediately without waiting for JavaScript. Astro sends only the minimal JavaScript needed to make interactive parts work, instead of the whole page's JavaScript. This approach reduces the amount of code the browser downloads and runs, making pages load faster and respond quickly to user actions. Hydrating only interactive components saves CPU and memory, improving performance further. Overall, Astro's method of building and sending minimal JavaScript leads to faster page loads and better user experience.

Practice

1. Why does Astro send less code to the browser compared to other frameworks?

easy

A. Because it uses server-side rendering only without any client code

B. Because it compiles code into a single large JavaScript file

C. Because it only sends the HTML and CSS needed, not all JavaScript by default

D. Because it disables CSS to reduce code size

Solution

1. Step 1: Understand Astro's code sending strategy

   Astro sends only the HTML and CSS needed for the page, avoiding unnecessary JavaScript by default.

2. Step 2: Compare with other options

   Other frameworks often send all JavaScript upfront or disable CSS, which is not true for Astro.

3. Final Answer:

   Because it only sends the HTML and CSS needed, not all JavaScript by default -> Option C

4. Quick Check:

   Less code sent = only needed HTML/CSS sent [OK]

Hint: Astro sends minimal code by default, mainly HTML and CSS [OK]

Common Mistakes:

• Thinking Astro sends all JavaScript upfront
• Believing Astro disables CSS to reduce size
• Confusing Astro with frameworks that bundle all code

2. Which of the following is the correct way to load JavaScript only when needed in Astro?

easy

A. ...

B.

C.

D. ...

Solution

1. Step 1: Identify Astro's client directives

   Astro uses client directives like client:load or client:visible to load JavaScript only when needed.

2. Step 2: Match correct syntax

   <MyComponent client:visible>...</MyComponent> is the correct way to load JS when the component becomes visible.

3. Final Answer:

   <MyComponent client:visible>...</MyComponent> -> Option A

4. Quick Check:

   Use client directives to load JS only when needed [OK]

Hint: Look for components with client:visible directive to defer JS [OK]

Common Mistakes:

• Using plain <script> tags without defer or client directives
• Confusing import inside <script> as lazy loading
• Using client:always which loads JS immediately

3. Given this Astro component snippet:

<MyWidget client:idle />

What happens to the JavaScript for MyWidget?

medium

A. It loads only when the browser is idle

B. It loads immediately when the page loads

C. It never loads, only HTML is sent

D. It loads only when the user clicks the widget

Solution

1. Step 1: Understand client:idle directive

   The client:idle directive tells Astro to load the JavaScript when the browser is idle, not immediately.

2. Step 2: Compare other options

   Loading immediately is client:load, never loading is incorrect, and loading on click is client:click.

3. Final Answer:

   It loads only when the browser is idle -> Option A

4. Quick Check:

   client:idle means load JS when browser is idle [OK]

Hint: client:idle defers JS until browser is free [OK]

Common Mistakes:

• Assuming client:idle loads JS immediately
• Confusing client:idle with client:click
• Thinking JS never loads with client:idle

4. You wrote this Astro code:

<MyComponent client:load />

But the JavaScript never loads on the client. What is the likely problem?

medium

A. Astro does not support client-side JavaScript

B. client:load is not a valid directive in Astro

C. You need to add defer attribute to the script tag

D. You forgot to import MyComponent in the Astro file

Solution

1. Step 1: Check if MyComponent is imported

   Astro requires components to be imported before usage; missing import means no JS bundle is generated.

2. Step 2: Validate client:load directive

   client:load is a valid directive, so the issue is not the directive itself.

3. Final Answer:

   You forgot to import MyComponent in the Astro file -> Option D

4. Quick Check:

   Missing import means JS won't load [OK]

Hint: Always import components before using client directives [OK]

Common Mistakes:

• Thinking client:load is invalid
• Assuming Astro disables client JS
• Adding defer attribute manually instead of using directives

5. You want to build a blog with Astro that loads JavaScript only for interactive widgets when visible, and sends static HTML for the rest. Which approach best achieves this?

hard

A. Use <script> tags with defer for all widgets

B. Use <MyWidget client:visible /> for widgets and normal Astro components for static content

C. Disable JavaScript globally and use only server rendering

D. Wrap all components in <AstroIsland client:load> to load JS immediately

Solution

1. Step 1: Identify how to load JS only when widgets are visible

   The client:visible directive loads JavaScript only when the widget scrolls into view, saving resources.

2. Step 2: Use normal Astro components for static content

   Static content can be rendered as plain HTML without JavaScript, improving performance.

3. Final Answer:

   Use <MyWidget client:visible /> for widgets and normal Astro components for static content -> Option B

4. Quick Check:

   client:visible loads JS on visibility, static content stays HTML [OK]

Hint: Use client:visible for widgets, normal components for static parts [OK]

Common Mistakes:

• Loading all JS immediately wastes resources
• Disabling JS globally breaks interactivity
• Using plain <script> tags misses Astro's lazy loading