Handling environment variables in Astro - Performance & Optimization

Performance: Handling environment variables

MEDIUM IMPACT

This affects page load speed and bundle size by controlling which environment variables are exposed to client-side code.

Exposing environment variables in Astro for client-side use

Astro

const apiKey = import.meta.env.PUBLIC_API_KEY;
// Only variables prefixed with PUBLIC_ are exposed to client
console.log(apiKey);

Limits exposed variables to only those needed on client, reducing bundle size and improving load speed.

📈 Performance Gainsaves 10-50kb in bundle size, faster LCP due to smaller JS payload

Exposing environment variables in Astro for client-side use

Astro

const apiKey = import.meta.env.PUBLIC_API_KEY;
// Using PUBLIC_ prefix for unnecessary or sensitive vars in client-side code
console.log(apiKey);

Exposes unnecessary or sensitive environment variables to client bundle, increasing bundle size and risking sensitive data leaks.

📉 Performance Costadds 10-50kb to client bundle depending on exposed env vars size, blocks rendering until bundle loads

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Exposing unnecessary env vars client-side	N/A	0	Increased due to larger JS	[X] Bad
Exposing only PUBLIC_ prefixed vars	N/A	0	Minimal JS size impact	[OK] Good

Rendering Pipeline

Environment variables are injected at build time. Variables without PUBLIC_ prefix are only available server-side, so client bundles stay smaller. Exposing too many variables increases JS size, delaying parsing and execution.

→Bundle Generation

→Network Transfer

→JS Parsing & Execution

⚠️ BottleneckJS Parsing & Execution due to larger bundle size

Core Web Vital Affected

LCP

This affects page load speed and bundle size by controlling which environment variables are exposed to client-side code.

Optimization Tips

1Only prefix environment variables with PUBLIC_ if they must be exposed to client.

2Avoid exposing sensitive or large environment variables to client-side code.

3Check client bundle size regularly to ensure environment variables are not bloating it.

Performance Quiz - 3 Questions

What is the main performance risk of exposing all environment variables to client-side code in Astro?

A Slower server response time

B Increased client bundle size slowing page load

C More DOM nodes created

D Higher CSS repaint cost

DevTools: Network

How to check: Open DevTools > Network tab > Filter by JS files > Check size of main JS bundle

What to look for: Smaller JS bundle size indicates fewer env vars exposed; large bundles suggest unnecessary exposure

Practice

1. In Astro, how do you access environment variables inside your code?

easy

A. Using import.meta.env

B. Using process.env

C. Using window.env

D. Using Astro.env

Solution

1. Step 1: Understand Astro environment variable access

   Astro uses the import.meta.env object to expose environment variables.

2. Step 2: Compare with other options

   process.env is common in Node.js but not in Astro client code. window.env and Astro.env are not valid in Astro.

3. Final Answer:

   Using import.meta.env -> Option A

4. Quick Check:

   Astro environment variables = import.meta.env [OK]

Hint: Remember: Astro uses import.meta.env for env variables [OK]

Common Mistakes:

• Using process.env which is Node.js specific
• Trying to access env variables via window object
• Assuming Astro has a global Astro.env object

2. Which prefix must you add to an environment variable name to make it accessible in Astro client-side code?

easy

A. PUBLIC_

B. SERVER_

C. CLIENT_

D. ASTRO_

Solution

1. Step 1: Identify the client-side environment variable prefix

   Astro requires environment variables to be prefixed with PUBLIC_ to expose them to client-side code.

2. Step 2: Eliminate incorrect prefixes

   SERVER_ is not used for client exposure, CLIENT_ and ASTRO_ are not recognized prefixes in Astro.

3. Final Answer:

   PUBLIC_ -> Option A

4. Quick Check:

   Client env prefix = PUBLIC_ [OK]

Hint: Use PUBLIC_ prefix for client env variables [OK]

Common Mistakes:

• Using SERVER_ prefix which is for server only
• Assuming CLIENT_ or ASTRO_ prefixes work
• Not prefixing variables and expecting client access

3. Given this Astro code snippet:

const apiKey = import.meta.env.PUBLIC_API_KEY;
console.log(apiKey);

If the environment variable PUBLIC_API_KEY is set to 12345, what will be logged in the browser console?

medium

A. "PUBLIC_API_KEY"

B. "12345"

C. Error: Variable not found

D. undefined

Solution

1. Step 1: Understand variable access in Astro client code

   Since the variable is prefixed with PUBLIC_, it is exposed to client code and accessible via import.meta.env.PUBLIC_API_KEY.

2. Step 2: Determine logged value

   The value of PUBLIC_API_KEY is set to 12345, so console.log(apiKey) outputs the string "12345".

3. Final Answer:

   "12345" -> Option B

4. Quick Check:

   PUBLIC_API_KEY value = "12345" [OK]

Hint: PUBLIC_ vars appear as strings in import.meta.env [OK]

Common Mistakes:

• Thinking the PUBLIC_ prefix doesn't make it client accessible, expecting undefined
• Confusing variable name with value
• Assuming error if variable exists

4. What is wrong with this Astro code snippet?

const secret = import.meta.env.SECRET_KEY;
console.log(secret);

Assuming SECRET_KEY is set in the environment but not prefixed with PUBLIC_.

medium

A. It will log the secret correctly in the browser console.

B. It will log the string "SECRET_KEY" instead of the value.

C. It will log null because secrets are blocked by Astro.

D. It will log "undefined" because SECRET_KEY is undefined in client code.

Solution

1. Step 1: Check environment variable accessibility rules

   Variables without the PUBLIC_ prefix are only available on the server side and not exposed to client code.

2. Step 2: Analyze client-side access attempt

   Trying to access import.meta.env.SECRET_KEY in client code results in undefined, so console.log(secret) logs "undefined".

3. Final Answer:

   It will log "undefined" because SECRET_KEY is undefined in client code. -> Option D

4. Quick Check:

   Non-PUBLIC_ vars are undefined client-side [OK]

Hint: Secrets need no PUBLIC_ prefix and stay server-only [OK]

Common Mistakes:

• Expecting secret to be available in client code
• Assuming Astro logs variable names instead of values
• Thinking Astro replaces missing vars with null

5. You want to use an API key in your Astro project. The key should be kept secret and never exposed to the browser. How should you handle this environment variable?

hard

A. Prefix the variable with PUBLIC_ and use it directly in client code.

B. Store the variable without prefix and access it in client code via import.meta.env.

C. Store the variable without PUBLIC_ prefix and access it only in server-side code.

D. Prefix the variable with SERVER_ and use it in client code.

Solution

1. Step 1: Understand security best practices for secrets

   Secrets like API keys should never be exposed to client code to avoid leaks.

2. Step 2: Use environment variable naming and access rules

   Variables without the PUBLIC_ prefix are only available on the server side in Astro, so store the API key without the prefix and access it only in server-side code.

3. Final Answer:

   Store the variable without PUBLIC_ prefix and access it only in server-side code. -> Option C

4. Quick Check:

   Secrets stay server-only without PUBLIC_ prefix [OK]

Hint: Keep secrets unprefixed and server-only for safety [OK]

Common Mistakes:

• Adding PUBLIC_ prefix and exposing secrets to client
• Trying to access secrets in client code
• Assuming SERVER_ prefix controls access