Environment variables on Deploy in Deno - Performance & Optimization

Performance: Environment variables on Deploy

MEDIUM IMPACT

This concept affects page load speed by controlling how configuration data is injected without increasing bundle size or blocking rendering.

Injecting configuration data securely without slowing page load

Deno

const API_KEY = Deno.env.get("API_KEY") ?? "";
// Environment variable injected at deploy, not bundled

Secrets are not bundled, reducing bundle size and avoiding render-blocking on load.

📈 Performance GainSaves 10-50kb bundle size, enables faster LCP by reducing blocking resources

Injecting configuration data securely without slowing page load

Deno

const API_KEY = "hardcoded_api_key";
// API key is bundled directly in client code

Hardcoding secrets in client code increases bundle size and exposes sensitive data, also blocking rendering until bundle loads.

📉 Performance CostAdds 10-50kb to bundle size, blocking rendering until download and parse complete

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Hardcoded secrets in bundle	Minimal	0	High due to large bundle parse	[X] Bad
Environment variables injected at deploy	Minimal	0	Low due to smaller bundle	[OK] Good

Rendering Pipeline

Environment variables are injected at deploy time and accessed at runtime without increasing client bundle size, reducing blocking during the critical rendering path.

→Network

→Script Parsing

→Style Calculation

⚠️ BottleneckNetwork and Script Parsing due to large bundles with embedded secrets

Core Web Vital Affected

LCP

This concept affects page load speed by controlling how configuration data is injected without increasing bundle size or blocking rendering.

Optimization Tips

1Never hardcode secrets in client-side bundles to avoid large bundle sizes.

2Inject environment variables at deploy time to keep bundles small and non-blocking.

3Use DevTools Network panel to verify bundle size and load performance.

Performance Quiz - 3 Questions

Why is hardcoding secrets in client-side code bad for performance?

A It improves caching of secrets

B It increases bundle size and blocks rendering longer

C It reduces network requests

D It speeds up script parsing

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page, and check bundle size and load time

What to look for: Look for large JS files containing secrets or config; smaller bundles indicate better use of environment variables

Practice

1. What is the main purpose of environment variables when deploying a Deno application?

easy

A. To keep secrets and settings outside the code for security and flexibility

B. To write all configuration directly inside the source code

C. To make the application run faster by hardcoding values

D. To store user data permanently on the server

Solution

1. Step 1: Understand environment variables role

   Environment variables store secrets and settings outside the code to avoid exposing sensitive data.

2. Step 2: Recognize deployment best practices

   Keeping secrets outside code allows changing settings without modifying the app, improving security and flexibility.

3. Final Answer:

   To keep secrets and settings outside the code for security and flexibility -> Option A

4. Quick Check:

   Environment variables = external secrets/settings [OK]

Hint: Environment variables hold secrets outside code [OK]

Common Mistakes:

• Thinking environment variables are for storing user data
• Hardcoding secrets inside source code
• Believing environment variables speed up code execution

2. Which of the following is the correct way to read an environment variable named API_KEY in a Deno script?

easy

A. const key = getenv("API_KEY");

B. const key = process.env.API_KEY;

C. const key = Deno.env.get("API_KEY");

D. const key = env.API_KEY;

Solution

1. Step 1: Recall Deno environment variable syntax

   Deno uses Deno.env.get("NAME") to access environment variables.

2. Step 2: Compare options

   const key = Deno.env.get("API_KEY"); matches Deno syntax; others are from Node.js or incorrect.

3. Final Answer:

   const key = Deno.env.get("API_KEY"); -> Option C

4. Quick Check:

   Deno.env.get("API_KEY") = correct syntax [OK]

Hint: Use Deno.env.get("VAR_NAME") to read env variables [OK]

Common Mistakes:

• Using Node.js syntax like process.env in Deno
• Calling undefined functions like getenv
• Accessing env variables without Deno.env.get

3. Given the following Deno code snippet deployed with environment variable PORT=8080, what will be the output?

const port = Deno.env.get("PORT") || "3000";
console.log(`Server running on port ${port}`);

medium

A. Server running on port 3000

B. Server running on port 8080

C. Server running on port undefined

D. Error: PORT is not defined

Solution

1. Step 1: Check environment variable value

   The environment variable PORT is set to "8080" in deployment.

2. Step 2: Evaluate fallback logic

   The code uses Deno.env.get("PORT") || "3000", so it uses "8080" because PORT exists.

3. Final Answer:

   Server running on port 8080 -> Option B

4. Quick Check:

   PORT=8080 overrides default 3000 [OK]

Hint: Env var set? Use it; else fallback value [OK]

Common Mistakes:

• Assuming fallback value always prints
• Expecting error if env var exists
• Confusing undefined with fallback

4. You deployed a Deno app but reading environment variables returns undefined. Which fix will solve this problem?

medium

A. Restart the app without setting variables

B. Change Deno.env.get to process.env

C. Hardcode variables inside the source code

D. Set environment variables in the deployment platform settings

Solution

1. Step 1: Identify cause of undefined env variables

   Undefined means variables are not set in the deployment environment.

2. Step 2: Apply correct fix

   Setting environment variables in deployment platform ensures Deno.env.get can read them.

3. Final Answer:

   Set environment variables in the deployment platform settings -> Option D

4. Quick Check:

   Env vars must be set in deploy settings [OK]

Hint: Always set env vars in deployment platform [OK]

Common Mistakes:

• Using Node.js syntax in Deno
• Hardcoding secrets instead of setting env vars
• Restarting app without setting variables

5. You want to deploy a Deno app that uses an environment variable MODE to switch between 'development' and 'production'. Which approach correctly uses environment variables to change app behavior safely?

hard

A. Set MODE in deployment settings and use Deno.env.get("MODE") in code to conditionally run features

B. Hardcode const MODE = "production" in source code and redeploy to change

C. Use a config file checked into source with MODE value

D. Ask users to input MODE at runtime every time

Solution

1. Step 1: Understand environment variable usage for modes

   Environment variables allow switching modes without changing code.

2. Step 2: Choose safe and flexible method

   Setting MODE in deployment and reading it with Deno.env.get enables safe conditional logic.

3. Final Answer:

   Set MODE in deployment settings and use Deno.env.get("MODE") in code to conditionally run features -> Option A

4. Quick Check:

   Env vars control modes safely without code changes [OK]

Hint: Use env vars to toggle modes, not hardcoding [OK]

Common Mistakes:

• Hardcoding mode and redeploying for changes
• Storing secrets or modes in config files checked into source
• Asking users to input mode every run