A file can be fetched, placed in a cache, entered in a module map, linked to dependencies, instantiated or evaluated. This lesson gives each state its own receipt so a waterfall entry is not mistaken for module execution.
This lesson continues The Gold Standard of Websites, the Gold Standard of Education and the How X Works hub. Every module URL, dependency edge, fetch time and evaluation result is an original teaching fixture. It explains the HTML processing model without claiming identical scheduling across browsers.
Keep transferred bytes, preload-cache entries, module-map entries, dependency fetches and evaluation as different states. A completed link request cannot prove that the module graph is ready or that any module code ran.
The WHATWG HTML Standard link-types section defines modulepreload as a specialized alternative to preload, its module-map effect and optional dependency fetching.
THE GOLD STANDARD · WEBSITES
modulepreload prepares a module-script fetch and module-map entry; ordinary preload uses the preload cache
Both link relations can fetch JavaScript bytes early, but they feed different browser machinery. modulepreload uses module-script fetching and stores the result in the document module map for later module loading. Ordinary preload places a response in the preload cache and must match the eventual request. An implementation may also fetch module dependencies from a modulepreload graph, yet the link load event does not wait for those dependencies.
Fast route
Start with the decisive rule.
Start this route
Measurement route
Build the browser evidence ledger.
Start this route
Comparison route
Separate the nearest lookalikes.
Start this route
Transfer route
Change the context and retest.
Start this route
Reporting route
State limits and continue reading.
Start this route
Chapter contents
Open the full chapter index
- 1. Give the short storage rule
- 2. Use the correct link relation
- 3. Apply module-script fetch settings
- 4. Place the result in the module map
- 5. Contrast the preload cache
- 6. Separate fetch from evaluation
- 7. Trace dependency discovery
- 8. Do not overread the link load event
- 9. Handle error evidence
- 10. Avoid duplicate requests
- 11. Respect document scope
- 12. Separate graph readiness from page readiness
- 13. Build a module ledger
- 14. Solve changed graph cases
- 15. Repair module shortcuts
- 16. State limits and misconceptions
- 17. Write a reproducible module record
- 18. Use authoritative sources and continue the route
1. Give the short storage rule
modulepreload uses module-script fetch behaviour and prepares the module map; ordinary preload prepares a reusable response in the preload cache.
Original worked example. main.js modulepreload becomes module-map entry M1 before import. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Replace it with rel=preload as=script. Bytes may arrive, but the module map still needs its module fetch path. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record relation, destination, credentials and storage target. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
2. Use the correct link relation
The author declares module intent with rel=modulepreload rather than hoping ordinary script preload has identical semantics.
Original worked example. Link L1 targets /main.js with rel=modulepreload. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Change to rel=preload while preserving the URL. The processing model changes. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Archive exact markup and resolved URL. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
3. Apply module-script fetch settings
Module scripts have defined request settings, including credential behaviour affected by crossorigin.
Original worked example. A same-origin module fetch matches later import settings. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Change the module to another origin without suitable CORS response. The prepared entry fails. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Store mode, credentials and response headers. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
4. Place the result in the module map
The useful prepared state is a module-map entry associated with the document and module type.
Original worked example. M1 is available when the module script is requested later. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Navigate to a new document. Do not assume its module map inherited M1. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Identify document, URL and module type. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
5. Contrast the preload cache
Ordinary preload can supply a later matching request but does not by itself create the module-map entry described for modulepreload.
Original worked example. P1 holds main.js bytes under preload settings. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Later module fetch differs in credentials and cannot reuse P1. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Track cache key and eventual consumer. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
6. Separate fetch from evaluation
modulepreload fetches and prepares; it does not mean top-level module code has executed.
Original worked example. M1 is ready at 90 ms; evaluation starts after the script is requested at 240 ms. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Never request the module. No evaluation occurs. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Log fetch, instantiation and evaluation separately. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
7. Trace dependency discovery
Implementations can use declared imports to fetch dependencies, but dependency handling is not identical to the top-level link receipt.
Original worked example. main.js imports chart.js and format.js; both start after graph discovery. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Make one import dynamic. It is not part of the same static preparation path. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Preserve graph edges and request initiators. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
8. Do not overread the link load event
The modulepreload link load event follows fetching the specified module and does not wait for all dependencies.
Original worked example. L1 fires load while chart.js is still pending. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Remove dependencies. The event timing becomes sufficient only for the top-level resource. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record top-level and dependency completion separately. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
9. Handle error evidence
A link error can identify failure of the specified module fetch; later graph or evaluation failures have their own evidence.
Original worked example. main.js fails CORS and L1 emits error. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. main.js succeeds but chart.js has syntax failure. The link event does not certify the graph. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Label fetch, parse, link and evaluation failures. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
10. Avoid duplicate requests
Correct matching can allow later module loading to reuse prepared work; mismatched attributes or URLs can trigger another fetch.
Original worked example. Resolved /main.js and settings match, so M1 is reused. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Add a query version only to the later import. A new URL requires new work. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Compare resolved URLs and fetch settings. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
11. Respect document scope
The prepared module map belongs to a document environment rather than a site-wide permanent module registry.
Original worked example. Document D4 prepares M1. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Open D5 in another tab. Verify its own requests instead of assuming reuse. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Record document and browsing context. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
12. Separate graph readiness from page readiness
Prepared modules can reduce discovery delay but do not certify rendering, interaction or application correctness.
Original worked example. Graph fetch finishes early but evaluation performs heavy synchronous work. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Split the heavy work. Preparation evidence stays the same while responsiveness improves. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Join timing evidence without merging claims. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
13. Build a module ledger
List link relation, target, request settings, module-map result, dependencies and evaluation receipt.
Original worked example. Ledger M8 shows L1, M1, edges to M2/M3 and later evaluation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Change only crossorigin. M1 becomes an error entry. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Require evidence for every state transition. If this check fails, mark the claim unavailable and repair the method before continuing.
Keep raw observations, lifecycle boundaries, calculations and conclusions separate so the first unsupported inference remains visible.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
14. Solve changed graph cases
Vary relation, URL, credentials, static dependency and document identity one at a time.
Original worked example. Five cases yield reuse, duplicate fetch, top-level failure, dependency failure and no evaluation. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Hide labels and reconstruct the first unmet condition. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Keep top-level and graph outcomes separate. If this check fails, mark the claim unavailable and repair the method before continuing.
Use a positive case, a clean negative case and an unavailable case. Unavailable evidence is not zero.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
15. Repair module shortcuts
Fetched is not in the module map, in the module map is not evaluated, and link load is not complete dependency readiness.
Original worked example. A report calls L1 load proof that the application ran. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Add module request and evaluation receipts. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Audit nouns and verbs against the processing model. If this check fails, mark the claim unavailable and repair the method before continuing.
Repeat the reasoning after changing one consequential premise while holding every other field fixed.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
16. State limits and misconceptions
modulepreload does not guarantee scheduling priority, dependency depth, faster experience or correct module code.
Original worked example. All modules arrive early but an import cycle exposes an application bug. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Repair the graph logic separately. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Name browser discretion and application obligations. If this check fails, mark the claim unavailable and repair the method before continuing.
Carry one plausible alternative through the ledger and choose the next observation that separates it from the leading account.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
17. Write a reproducible module record
A reviewer should rebuild the link, fetch, map, graph and evaluation sequence.
Original worked example. Record M12 stores HTML, resolved URLs, request headers, module entries, graph edges and clocks. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. A browser update changes dependency fetching. Append M13. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Archive waterfall and console evidence with version. If this check fails, mark the claim unavailable and repair the method before continuing.
Write the expected result before checking the outcome, then preserve conflicts instead of smoothing them away.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Previous chapter · Contents · Next chapter
18. Use authoritative sources and continue the route
The HTML Standard defines modulepreload and ordinary preload distinctions; companion lessons cover current-page preload, future prefetch and fetch priority.
Original worked example. Continue through them without treating all early JavaScript fetches as equivalent. The identifiers, timestamps and observations are explicit so the reader can reconstruct the decision instead of trusting a label.
Changed-context transfer. Save the living-standard date and tested browser context. State what changed, predict the consequence and revise only the conclusion that depended on that condition.
Practical evidence check. Store the WHATWG URL and evidence bundle. If this check fails, mark the claim unavailable and repair the method before continuing.
Archive exact sources, versions, calculations and receipts so another reader can reproduce the conclusion.
Before closing, reconcile the worked example against the chapter rule: identify the eligible evidence, recompute the result, test the changed condition, and mark the first unsupported inference. Preserve the original inputs beside the revised conclusion so another reader can tell what changed. End the chapter with three sentences: what the evidence establishes, what it does not establish and what observation or calculation would change the conclusion. This keeps the lesson useful when the browser state, observation window or implementation context changes. A strong record also names the datum, denominator, section or coordinate system that governed the decision, so a later reader can repeat the reasoning without importing an unstated shortcut.
Grouped reading routes
Core route
Companion lessons
- Separating Navigation Preload Responses from Service Worker Fetch Handling
- Separating 103 Early Hints from Final Response Headers
- Separating skipWaiting Activation from clients.claim Control
Related specialist lessons
Sources and further study
WHATWG HTML Standard: link types. Used for the standard definitions, material mechanisms or method limits developed in this lesson.
The worked examples and transfer checks are developed here and state their own assumptions. The linked sources support the underlying browser lifecycle, protocol and measurement principles.
Return to contents · Return to The Gold Standard of Websites