Module 14: Internet & Loading — Design & Code Foundations

01

How the Web Works

Understanding the journey from URL to rendered page helps you optimize each step of the process.

Browser

DNS

TCP

TLS

Server

The Request Journey

Every request: DNS lookup (find IP), TCP connection (3-way handshake), TLS negotiation (encryption), then finally the HTTP request. Each step adds latency.

Key point: Connection overhead can exceed content download time

HTML document~5KB

CSS stylesheet~50KB

JavaScript bundle~300KB

Images~500KB

Server Response

Server sends HTML first. Browser parses it, discovers CSS/JS/images, makes more requests. Each resource blocks or delays rendering differently.

Key point: HTML is small, but it triggers many more requests

1Parse HTML → DOM tree

2Parse CSS → CSSOM tree

3Combine → Render tree

4Layout → Calculate positions

5Paint → Draw pixels

Browser Rendering

Browser builds DOM from HTML, CSSOM from CSS, combines them into render tree, calculates layout, then paints pixels. CSS blocks rendering; JS blocks parsing.

Key point: CSS in , JS at end of or with defer

CSS

Blocks render

JS (normal)

Blocks parse

JS (defer)

Non-blocking

Images

Non-blocking

Render Blocking

CSS blocks rendering - nothing paints until CSS loads. Regular JS blocks HTML parsing. defer/async JS loads without blocking. Images load asynchronously.

Key point: Critical CSS inline, defer non-critical JS

02

Core Web Vitals

Google's metrics for user experience. These affect SEO rankings and measure what users actually care about.

≤2.5s

Good

≤4.0s

Needs work

>4.0s

Poor

Largest Contentful Paint

LCP measures when the largest content element becomes visible. Usually a hero image or headline. Target: under 2.5 seconds.

Key point: Optimize hero images and fonts for fast LCP

≤100ms

Good

≤300ms

Needs work

>300ms

Poor

First Input Delay

FID measures delay from first user interaction to browser response. Heavy JavaScript blocks the main thread. Target: under 100ms.

Key point: Break up long JavaScript tasks, use web workers

≤0.1

Good

≤0.25

Needs work

>0.25

Poor

Cumulative Layout Shift

CLS measures unexpected layout shifts. Images without dimensions, late-loading ads, and font swaps cause shifts. Target: under 0.1.

Key point: Always set width/height on images and embeds

Replacing FID in 2024

INP ≤200ms

Measures ALL interactions, not just first

Interaction to Next Paint

INP measures responsiveness throughout the page lifecycle, not just first interaction. Better represents real user experience.

Key point: Optimize all interactions, not just initial load

03

Optimization Strategies

Practical techniques to make pages load faster and feel more responsive.

Original JPEG2.4 MB

Compressed JPEG400 KB

WebP180 KB

AVIF120 KB

Image Optimization

Use modern formats (WebP, AVIF), compress aggressively, serve appropriate sizes with srcset, lazy load below-fold images.

Key point: Images are usually the biggest opportunity

/* Before: 500KB */
import _ from 'lodash';
/* After: 4KB */
import debounce from 'lodash/debounce';
/* Also: */
• Minify CSS/JS
• Tree shaking
• Code splitting

Code Optimization

Import only what you need, minify everything, tree-shake unused code, split bundles for lazy loading. Every KB matters on mobile.

Key point: Bundle analyzer shows where bloat hides

Browser Cache

Cache-Control headers, ETags

CDN Cache

Edge servers close to users

Service Worker

Offline support, custom caching

Caching Strategies

Cache static assets aggressively (1 year). Use content hashes in filenames for cache busting. CDNs reduce latency by serving from edge locations.

Key point: The fastest request is one that never happens

<link rel="preload"> - Load critical resources early

<link rel="prefetch"> - Load next page resources

loading="lazy" - Defer off-screen images

<script defer> - Non-blocking JS

Loading Strategies

Preload critical resources (fonts, hero image). Prefetch likely next pages. Lazy load everything below the fold. Defer non-critical JS.

Key point: Prioritize what users see first

04

Perceived Performance

How fast something feels matters as much as how fast it actually is. Perception can be designed.

Skeleton Screens

Skeleton screens show the page structure before content loads. Users perceive this as faster than spinners because progress is visible.

Key point: Skeletons feel 15-20% faster than spinners

Indeterminate - unknown time

Determinate - shows progress

Progress Indicators

Show progress whenever possible. Determinate progress (showing percentage) feels faster than indeterminate (spinner). Users wait longer when they see progress.

Key point: Any indication is better than nothing

1. User clicks "Like"

2. UI updates immediately ❤️

3. Request sent in background

4. If fails, revert + show error

User sees instant response

Optimistic Updates

Update UI before server confirms. Most operations succeed, so show success immediately. Roll back if the request fails. Twitter, Facebook use this.

Key point: Assume success, handle failure gracefully

Animation: Progress bars that accelerate at the end feel faster

Distraction: Interesting loading content makes waits feel shorter

Early start: Show header immediately, load content progressively

Perception Tricks

Animations that speed up feel faster than linear ones. Content during waits makes them feel shorter. Show something immediately, even if incomplete.

Key point: Design the wait, not just the content

05

Network Conditions

Not everyone has fast internet. Design for real-world conditions, not just your office WiFi.

Your office100+ Mbps

Home WiFi avg25 Mbps

4G mobile10 Mbps

3G mobile1 Mbps

Emerging markets0.5 Mbps

Real World Speeds

Half of web traffic is mobile. Many users have slow, unreliable connections. Test on throttled connections, not just your fast network.

Key point: DevTools Network tab can simulate slow connections

Slower CPU

JS executes 3-5x slower than desktop

Variable connection

Signal drops in elevators, tunnels

Data costs

Users pay per MB in many countries

Mobile Constraints

Mobile isn't just small screens. CPUs are slower, connections are unreliable, data may cost money. Every byte costs your users.

Key point: Test on real devices, not just emulators

✓ Works without JavaScript

✓ Images have alt text fallback

✓ Fonts fall back to system fonts

✓ Critical content loads first

Graceful Degradation

Build for resilience. Core content should work without JS. Provide fallbacks for everything. Progressive enhancement over graceful degradation.

Key point: The best request is no request

📴

Service Workers

Cache critical assets for offline use

Queue actions to sync when online

Offline Support

Service workers can cache your app for offline use. Queue user actions and sync when connection returns. Essential for unreliable networks.

Key point: PWAs work offline and install like native apps

09

Instant vs Delivered

Print is instant once in hand. Web content must be fetched, transmitted, and rendered.

Access Speed

Print

📖

Instant

Once printed, access is immediate

Web

⏳

Depends on network

Every visit requires loading

Content Size

Print

Fixed

All pages same weight

Physical size doesn't affect reading speed

Web

Variable

More bytes = slower

Every KB adds load time

Reliability

Print

Always works

No connection needed

Works anywhere, anytime

Web

Requires connection

Can fail

Network dependency is a weakness

10

The Psychology of Waiting

Understanding how humans perceive time helps design better loading experiences.

0-100ms: Feels instant

100-300ms: Slight delay noticed

300-1000ms: Machine is working

1000ms+: User loses focus

Time Perception

Under 100ms feels instant. 100-1000ms, users notice but stay focused. Over 1 second, attention wanders. Over 10 seconds, users leave.

Key point: Target 100ms for interactions, 1s for navigation

"Is it working?"

"Should I refresh?"

"Did I click?"

"Is my connection bad?"

Uncertainty makes waits feel longer

Wait Anxiety

Unexplained waits cause anxiety. Users don't know if it's working, broken, or their fault. Progress indicators reduce this anxiety.

Key point: Always communicate what's happening

Users remember the end of experiences

A fast finish feels faster overall

Duration Memory

The peak-end rule: people judge experiences by the peak and end, not the average. Progress bars that accelerate at the end are remembered as faster.

Key point: Make the end feel fast

⏳

Empty spinner

Feels long

📝

Tips while waiting

Feels shorter

Occupied Time

Occupied time feels shorter than unoccupied time. Show tips, animations, or partial content during loads. Disney parks use this with queues.

Key point: Give users something to do or look at

11

Real-World Performance

How top sites handle loading and performance.

Google

~500ms total load time

Principles Identified:

Minimal HTML Homepage is under 200KB total

Critical CSS Styles inlined for instant render

Lazy loading Scripts load after content visible

Key insight: Google proves that simple can be fastest. Every millisecond of search delay costs revenue.

Skeleton screens everywhere

Principles Identified:

Skeleton UI Placeholders appear before images load

Progressive JPEG Images render blurry then sharp

Predictive loading Preloads content you might watch

Key insight: Netflix optimizes perceived performance - you see structure immediately even on slow connections.

Edge-rendered pages

Content served from nearest CDN

Principles Identified:

Edge computing Pages rendered close to users

Aggressive caching Static content cached for a year

Optimized images Automatic WebP conversion

Key insight: Shopify handles millions of stores by pushing rendering to the edge - closer to users.

12

Performance Failures

Common mistakes that make pages slow and users frustrated.

Failure: Blocking Everything

<script src="huge.js"></script>
<!-- Page waits... -->

Fix: Use defer/async for scripts

<script src="huge.js" defer></script>
<!-- Page renders immediately -->

Rule: Scripts in without defer block rendering. Add defer to non-critical JS. Critical JS should be minimal and inline.

Failure: Unoptimized Images

hero.png - 4MB

Straight from camera

Fix: Compress and use modern formats

hero.webp - 150KB

Compressed, right size, modern format

Rule: Never use images straight from camera. Resize to actual display size, compress, use WebP/AVIF with fallbacks.

Failure: Layout Shift

Text here

↓ Ad loads, pushes content down ↓

Fix: Reserve space for dynamic content

Text here

Reserved ad space

Rule: Set explicit width/height on images, embeds, and ads. Reserve space before content loads to prevent shifts.

Failure: No Feedback

*clicks* ... nothing happens?

Fix: Always show loading state

User knows action is processing

Rule: Every action needs feedback. Show loading states, disable buttons during submission, provide progress when possible.

13

Performance Tests

Quick checks to ensure your site loads quickly.

01

3G Test

Tests: Real-world speed

Open DevTools, set Network to Slow 3G, clear cache, reload. Is the page usable within 5 seconds? Is LCP under 4s?

DevTools → Network → Slow 3G

02

Lighthouse Audit

Tests: Overall performance

Run Lighthouse in DevTools (Performance mode). Target 90+ score. Fix any red metrics first.

90+

Target Lighthouse score

03

Bundle Check

Tests: Code weight

Check your JS bundle size. Is it under 200KB gzipped? Use webpack-bundle-analyzer to find bloat.

JS: <200KB gzip

CSS: <100KB gzip

Total: <1MB initial

04

CLS Check

Tests: Visual stability

Reload page on slow connection. Does anything jump around? Do images push content? Do ads cause shifts?

Nothing should move unexpectedly

14

Performance Implementation

HTML and CSS patterns for faster loading.

Critical CSS via CSS

Inline critical - Above-fold styles render immediately
Preload async - Full CSS loads without blocking
noscript fallback - Works without JavaScript

Tip: Use tools like Critical to extract above-the-fold CSS automatically.

Image Loading via CSS

srcset - Browser picks right size
loading="lazy" - Defer off-screen images
width/height - Prevents layout shift
decoding="async" - Non-blocking decode

Tip: Always include width and height to reserve space and prevent CLS.

/* System font stack (no download) */
body {
  font-family: 
    system-ui, 
    -apple-system, 
    BlinkMacSystemFont, 
    'Segoe UI', 
    Roboto, 
    sans-serif;
}

/* If using web fonts */
@font-face {
  font-family: 'Custom';
  src: url('font.woff2') format('woff2');
  font-display: swap; /* Show fallback immediately */
}

Font Loading via CSS

System fonts - No download needed, instant
font-display: swap - Text visible before font loads
WOFF2 - Best compression for web fonts
Subset fonts - Only include characters you need

Tip: System fonts are fastest. If using custom fonts, preload them and use font-display: swap.

Resource Hints via CSS

dns-prefetch - Resolve DNS early
preconnect - Full connection setup
preload - Load critical resources ASAP
prefetch - Load likely next pages

Tip: Don't over-prefetch. Only hint resources that will definitely be used.

15

Self-Assessment

Test your understanding of web performance.

Q1

What are the three Core Web Vitals?

Click to reveal

Q2

Why does CSS block rendering but images don't?

Click to reveal

Q3

What causes Cumulative Layout Shift and how do you prevent it?

Click to reveal

Q4

Why do skeleton screens feel faster than spinners?

Click to reveal

Q5

What is the difference between preload and prefetch?

Click to reveal

Internet & Loading

Core Concepts

How the Web Works

Core Web Vitals

Optimization Strategies

Perceived Performance

Network Conditions

Print vs Web

Instant vs Delivered

Science & Psychology

The Psychology of Waiting

Real-World Examples

Real-World Performance

Common Failures

Performance Failures

Visual Tests

Performance Tests

3G Test

Lighthouse Audit

Bundle Check

CLS Check

CSS Implementation

Performance Implementation

Self-Assessment

Self-Assessment

Key Takeaways