Web Performance and Deployment

🎯Learning Objectives

• Level28 protected application boundaries.
• Level29 asks how to deliver the same correct experience with less delay, smaller transfers and predictable releases.
• Distinguish a measurement from an estimate, cache freshness from validation, and deployment success from live-site correctness.

measure → identify bottleneck → change → verify → release

Outcome worksheet: Explain the change in user-visible behavior as well as its effect on transferred bytes.

🗺️Follow the Page Loading Journey

• A page visit includes connection work, a document response, discovery of dependent resources, parsing, rendering and script execution.
• Some work overlaps; a simple sum of file sizes does not predict when the page becomes useful.
• A small blocking script can delay discovery and rendering even when images dominate bytes.

document request
critical CSS and main content
script execution and interaction
secondary content

• Investigation sequence: In the network waterfall, inspect dependencies and timing.
• In the performance trace, inspect main-thread work; a fast download does not imply a responsive page.

📊Measure User Experience

• Largest Contentful Paint describes main-content loading, Interaction to Next Paint describes interaction responsiveness, and Cumulative Layout Shift describes unexpected visual movement.
• Use field observations across representative devices alongside repeatable laboratory tests.
• A single favorable run cannot establish what most visitors experience.

page + release + device/network conditions
loading / interaction / layout movement
repeat runs + field distribution

• Measurement record: Current good targets are LCP at most2.5 seconds, INP at most200 milliseconds and CLS at most0.1, assessed at the75th percentile for mobile and desktop separately.
• These metrics do not measure every aspect of usability.

🧪Set a Baseline and a Performance Budget

• Choose a meaningful page and interaction, record the current release and repeat conditions, then decide an acceptable budget for initial resources and responsiveness.
• A budget is a project decision, not a universal rule.
• Compare equivalent scenarios before claiming an improvement.

initial script transfer: project-defined limit
main image: correct display dimensions
interaction: no unnecessary synchronous work

• Budget example — chosen for a practice project: Use cold and repeat visits, a slower device, keyboard interaction and realistic content.
• Preserve functionality and accessibility while optimizing.

📦Reduce Resource Work

• Remove unused code and duplicate dependencies before adding complex delivery tricks.
• Minification removes unnecessary source bytes; compression changes transfer encoding; neither removes the execution cost of unused JavaScript.
• Split optional features when their discovery and interaction requirements justify it.

is this library needed on this page?
is the same feature loaded twice?
can optional work start after user intent?

• Code review questions: Do not split so aggressively that dependency chains create new delays.
• Check bundle composition and the actual execution trace after each change.

🖼️Images and Stable Layout

• Serve appropriately sized images, choose a suitable format, and reserve layout space with dimensions or an aspect ratio.
• Lazy-load suitable offscreen content.
• Do not lazy-load the likely main above-the-fold image merely to reduce initial bytes; delaying it can harm main-content loading.

<img src="diagram.webp" alt="Request passing through a cache"
     width="800" height="450" loading="lazy">

• Offscreen image illustration: This source is illustrative and requires the actual file.
• Dimensions reserve space; responsive image candidates can avoid transferring an unnecessarily large asset.

⚙️Script Loading and Main-Thread Work

• For external classic scripts, defer allows parsing to continue and preserves ordered execution after parsing.
• Async executes when ready without preserving dependency order.
• Module scripts defer by default unless configured otherwise.
• Avoid loading dependent scripts as independent async tasks.

<script src="lesson-controls.js" defer></script>

• Classic script with a DOM dependency: Choose ordering deliberately.
• Then reduce long synchronous tasks, measure event handlers, and avoid repeating expensive DOM work on every scroll event.

🗂️Browser, Shared and Application Caches

• A browser cache is private to a client; a shared cache may serve many clients.
• Application-managed caches and service workers introduce additional logic.
• A CDN hit does not prove that the browser fetched the latest representation, and a browser cache hit may skip the CDN entirely.

browser → shared edge → origin
service worker: separate application-controlled interception

• Cache boundary map: Identify which layer serves the response before clearing caches.
• Never place personalized data into a shared cache accidentally; identity and permissions must remain correct.

⏳Freshness — Reuse Without Validation

• An explicit max-age defines a freshness lifetime.
• While a stored response is fresh, a normal eligible request may reuse it without contacting the origin.
• At the lifetime boundary it is stale.
• Real age calculations include response metadata and time in transit; the lab uses one simplified local clock.

Cache-Control: public, max-age=60
ETag: "release-1"

• Illustrative response headers: A release published at the same URL does not directly alter an already fresh browser entry.
• A short lifetime trades more validation opportunities for fewer long-lived stale views.

🔎Validation — Ask Whether It Changed

• A stale stored response with a validator can be checked using a conditional request.
• If-None-Match supplies the stored ETag.
• An unchanged representation may produce304 without a response body; the client continues using its stored content and updates metadata.
• A changed representation needs a full response.

GET /release.txt
If-None-Match: "release-1"

unchanged →304, reuse stored body
changed →200, replace stored body

• Conditional read illustration: Validation still requires network work.
• Do not describe a304 as a fresh cache hit or attempt to parse its absent body as a new document.

🏷️Choose a Cache Policy for the Resource

• No-cache permits storage but requires validation before reuse.
• No-store directs HTTP caches not to store the response.
• Private restricts shared-cache storage; it does not itself make a response uncacheable in a browser.
• Freshness and permission to store are separate decisions.

changing document: Cache-Control: no-cache
sensitive response: Cache-Control: no-store
fingerprinted public asset: long max-age + immutable

• Different resource contracts: These are examples, not a blanket configuration for this website.
• No-store is not a promise to erase previously stored copies; application caches and actual provider settings need separate attention.

🗜️Compression and Representation Variants

• A suitable content coding can reduce transferred text bytes when the client and server support it.
• Already compressed media may gain little.
• Content-Encoding describes the representation coding, and Vary: Accept-Encoding helps caches distinguish negotiated variants.
• Savings depend on actual content and configuration.

Accept-Encoding: gzip, br

Content-Encoding: gzip
Vary: Accept-Encoding

• Negotiation illustration: The lab uses fixed12000-byte identity and4000-byte gzip fixture bodies.
• It runs no compressor and predicts no latency.
• Byte counters exclude headers, connection costs and processing.

🚀Release Identity and Safe Deployment

• Connect an accepted source commit to a successful production build and the domain serving it.
• Review the actual output directory and required assets.
• A green build proves completion of its configured steps; it does not prove all pages, APIs or custom-domain routes work.

commit → production build → deployed version
custom domain → document → referenced asset versions

• Release sequence: Publish new fingerprinted asset URLs with document references to that release.
• Keep old assets available long enough for older documents.
• A query-string version can identify a resource only if the relevant cache key respects it.

🧭Diagnose an Update That Is Not Visible

• First verify the commit, production branch, deployment status and serving domain.
• Then inspect the returned document, asset URL, response headers and browser network result.
• Distinguish build cache from delivery cache: cached build dependencies are not the same as a stored browser response.

correct commit and output?
correct production domain?
old document or old referenced script?
browser / edge / service-worker layer?

• Diagnosis checklist: Inspect actual headers from the serving path.
• For Cloudflare static assets a _headers file can configure matching responses, while responses generated by Worker code need headers attached in that code.
• This lesson changes neither production configuration nor cache policies.

✅Verify, Monitor and Roll Back

• Smoke-test navigation, key interactions, error outcomes and backend calls on the production domain after deployment.
• Compare performance under equivalent conditions and monitor real-user regressions.
• Define a rollback release and confirm document/asset compatibility before relying on it.

before/after under same conditions
functional + keyboard + mobile checks
release ID + rollback target
observed errors and performance

• Review record: Rolling back a frontend does not automatically reverse database migrations or invalidate every stored response.
• Coordinate backend contracts and cache strategy rather than treating redeploy as universal recovery.

🧪Premium Interactive — Release Cache Decision Lab

• This synchronous local model has one fictional stable URL /release.txt, origin release1 and an empty private browser cache.
• Choose max-age60, no-cache or no-store.
• The origin policy stays fixed within an experiment.
• Policy or coding changes start a new experiment and clear all fixtures/counters; that reset is not how a production policy change purges existing caches.

• Request once for a simulated200.
• With max-age60, another request before age60 uses stored content without network.
• At age60 it validates: unchanged origin gives304 with no body; changed origin gives200.
• No-cache validates every stored reuse.
• No-store transfers a new200 each time and keeps no cache entry.

• Publish increments the origin version at the same URL without changing the browser entry.
• Advance moves a toy clock by whole0–3600 seconds, up to86400 total.
• Both actions clear previous result panels; they do not send requests.
• At most20 origin releases are allowed before reset.

• Identity and gzip represent fixed estimated body sizes12000 and4000 bytes.
• They are not actual encoded content and provide no latency or Web Vitals measurement.
• The counters exclude headers/TLS/processing.
• The model omits real Date/Age, Vary matching, reloads, shared caches, service workers, failures and concurrent requests.
• Only the study-completion marker uses local storage.

No request yet.

No trace yet.

No response yet.

No representation yet.

🛠️Debugging — Locate the Delivery Decision

• If a newly published version is not visible, inspect the stored entry and age first.
• A fresh max-age entry is allowed to show the previous representation.
• Advancing time alone never fetches a new release; Request performs the delivery decision.

• A304 means the origin was contacted and the stored representation was still valid.
• It transfers no new body in this lab but still increases the network-request count.
• No-store repeats full transfers.
• Coding changes reset the experiment so two variant caches are never mixed.

• For a real deployment inspect the actual document and its referenced asset URLs, the serving branch/domain, response headers and service-worker behavior.
• These teaching counters cannot diagnose production latency or prove cache configuration.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Explain Delivery Decisions

💻Extra Practice — Follow a Cached Release

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — A Measured Release Plan

• Choose a real page and interaction, record a baseline and release identifier, and propose one change tied to an observed bottleneck.
• Keep functionality and keyboard/mobile behavior intact.
• Compare equivalent measurements after the change.

• Specify separate policies for changing documents, fingerprinted public assets and sensitive responses.
• Define release-compatible asset references, backend contracts, smoke checks and a rollback target.
• Do not treat a browser refresh as a deployment verification procedure.

• Predict cold, fresh, stale-unchanged and stale-changed outcomes in the lab, including network counts, body bytes and visible versions.
• Verify actual production headers and performance independently.
• Next: Level30 — Web Technologies Capstone and Placement.