) => void;
+ removeBookmark: (id: string) => void;
+ clearBookmarks: () => void;
+ exportBookmarks: () => string;
+ importBookmarks: (data: string) => boolean;
+}
\ No newline at end of file
diff --git a/tutorials/html/14-seo/index.mdx b/tutorials/html/14-seo/index.mdx
index e1034d226..e2c27154f 100644
--- a/tutorials/html/14-seo/index.mdx
+++ b/tutorials/html/14-seo/index.mdx
@@ -292,8 +292,6 @@ Test what you already believe about SEO:
## What Is in This Section
-### Foundations
-
## Tools You Will Use
diff --git a/tutorials/html/15-performance/async.mdx b/tutorials/html/15-performance/async.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/15-performance/core-web-vitals.mdx b/tutorials/html/15-performance/core-web-vitals.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/15-performance/critical-resources.mdx b/tutorials/html/15-performance/critical-resources.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/15-performance/defer.mdx b/tutorials/html/15-performance/defer.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/15-performance/dns-prefetch.mdx b/tutorials/html/15-performance/dns-prefetch.mdx
new file mode 100644
index 000000000..5ab5671c0
--- /dev/null
+++ b/tutorials/html/15-performance/dns-prefetch.mdx
@@ -0,0 +1,432 @@
+---
+id: html-perf-dns-prefetch
+title: "DNS Prefetch in HTML"
+sidebar_label: "DNS Prefetch"
+sidebar_position: 6
+slug: /html/performance/dns-prefetch
+description: "Learn link rel=dns-prefetch: a tiny, cheap hint that looks up a server's address early. See what DNS is, what the hint saves, how it differs from preconnect, and which hosts deserve it."
+keywords:
+ - dns-prefetch
+ - link rel dns-prefetch
+ - DNS lookup
+ - dns-prefetch vs preconnect
+ - third-party hosts
+ - connection time
+ - HTML performance
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, dns-prefetch, resource-hints, third-party, frontend]
+---
+
+import {useState} from 'react';
+import AdsComponent from '@site/src/components/AdsComponent';
+
+export function connectionWait(o) {
+ const hintAt = 200;
+ const total = o.dns + o.tcp + o.tls;
+ if (o.needAt <= hintAt) return {none: total, dnsPrefetch: total, preconnect: total};
+ return {
+ none: total,
+ dnsPrefetch: Math.max(0, hintAt + o.dns - o.needAt) + o.tcp + o.tls,
+ preconnect: Math.max(0, hintAt + total - o.needAt)
+ };
+}
+
+export function ConnectionLab() {
+ const [dns, setDns] = useState(60);
+ const [tcp, setTcp] = useState(60);
+ const [tls, setTls] = useState(100);
+ const [needAt, setNeedAt] = useState(800);
+ const w = connectionWait({dns: dns, tcp: tcp, tls: tls, needAt: needAt});
+ const presets = [
+ ["Nearby", 20, 20, 40],
+ ["Typical", 60, 60, 100],
+ ["Far or slow", 150, 200, 300]
+ ];
+ const rows = [
+ ["No hint", w.none, "#c0392b"],
+ ["dns-prefetch", w.dnsPrefetch, "#b9770e"],
+ ["preconnect", w.preconnect, "#1e8449"]
+ ];
+ const slider = function (id, label, value, set, max) {
+ return (
+
+
+
+
+
+ );
+ };
+ return (
+
+
+ {presets.map(function (p) {
+ return (
+
+ );
+ })}
+
+ {slider("cl-dns", "DNS lookup", dns, setDns, 300)}
+ {slider("cl-tcp", "Connecting", tcp, setTcp, 300)}
+ {slider("cl-tls", "Security handshake", tls, setTls, 400)}
+ {slider("cl-need", "The page first needs this host at", needAt, setNeedAt, 2000)}
+
Time the page waits for the connection
+ {rows.map(function (r) {
+ return (
+
+ );
+ })}
+
+ dns-prefetch saves at most the DNS part ({dns} ms). Preconnect can save the whole setup, if it has time to finish before the page needs the host.
+
+
+ This is a simplified model. It assumes the hint is found at 200 ms and that each step takes the time you set. Real numbers vary a lot with distance, network, and caching, so measure your own.
+
+
+ {hostItems.map(function (h, i) {
+ const right = picked[i] === h.answer;
+ return (
+
+
+
+
+ {checked ? (
+
+ {right ? "Right. " : "Not quite. "}
+ {h.why}
+
+ ) : null}
+
+ );
+ })}
+ {!checked ? (
+
+ ) : (
+
+ Score: {score} of {hostItems.length}.{" "}
+
+
+ )}
+
+
+## The Big Idea
+
+A DNS prefetch is a `link` element with the address of a host. Only the host matters, not the file.
+
+
+
+
+```html title="index.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the lab, compare the three bars. Notice how `dns-prefetch` only trims the DNS part of the wait, while `preconnect` can remove much more, if it has enough time to finish.
+
+## What Is DNS?
+
+Think of DNS as the phone book of the internet. You know a name, `cdn.example.com`, and the phone book gives you a number, such as `203.0.113.7`. Only then can your browser "call" the server.
+
+The lookup asks a chain of servers, and the answers are remembered for a while, by the browser, your device, and your internet provider. So a host you have used recently is often quick, and a host you have never used may take longer. The difference can be small (a few milliseconds) or large (hundreds, on a slow or distant network), and it varies a lot.
+
+## The Steps of a New Connection
+
+Fetching a file from a **new** server takes several steps before any data arrives. Each hint covers different steps.
+
+| Step | What happens | `dns-prefetch` | `preconnect` |
+| :-- | :-- | :-- | :-- |
+| 1. DNS lookup | Find the server's address | Yes | Yes |
+| 2. Connect | Open a line to the server | No | Yes |
+| 3. Secure handshake | Agree on encryption (for https) | No | Yes |
+| 4. Request | Ask for the file | No | No |
+
+So `dns-prefetch` does one step of three. That is why it is so cheap, and also why it saves less. Next lesson, [Preconnect](./preconnect), covers the full set.
+
+## How to Write It
+
+```html
+
+```
+
+- **Use the origin only:** the scheme and host, such as `https://cdn.example.com`. A path adds nothing, because DNS cares only about the host.
+- **You do not need `crossorigin`.** A lookup is the same however the files are later fetched.
+- **Add one line per host,** and keep the list short.
+
+## When to Use It
+
+`dns-prefetch` is a good fit for hosts that are **third-party** (not your own site), and that the page **may need** later, but not at once:
+
+- Analytics and tag managers
+- Chat or support widgets
+- Embedded videos or maps further down the page
+- Social buttons
+- Any host that comes up after a script runs
+
+It does nothing for your own site, because the browser has already looked up the host that served the page.
+
+## Pairing It with Preconnect
+
+A very common pattern puts both hints on the same host:
+
+```html
+
+
+```
+
+Why both? Browsers that do not understand `preconnect` can still do the DNS lookup, and some browsers limit how many connections they will open early. The lookup acts as a safety net. Check [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/dns-prefetch) for current browser support of each.
+
+## Sort the Hosts
+
+Here is a bakery page that uses seven hosts. For each one, choose the hint it deserves, or none.
+
+
+<>
+
+
+
+
+:::tip
+A simple rule: **needed straight away, so `preconnect`. Maybe needed later, so `dns-prefetch`. Your own site or unlikely, so nothing.**
+:::
+
+## When It Does Not Help
+
+- **Your own site.** The lookup is already done.
+- **Hosts the page never uses.** You pay a small cost for nothing.
+- **Hosts used much later.** The answer is only remembered for a limited time, so a lookup that is far ahead of its use may be repeated.
+- **Many hosts.** A long list adds noise, and each lookup uses a little battery and network on mobile.
+- **A visitor with a fast, warm DNS cache.** The lookup may be nearly free anyway.
+
+Because the cost is so low, a few unneeded `dns-prefetch` hints do little harm. But a careful list is still better than a long one.
+
+## Checking That It Worked
+
+1. Open DevTools, then **Network**, and reload.
+2. Click a request to a third-party host, and open the **Timing** tab.
+3. Look at **DNS Lookup**. With a good prefetch it may be zero, or not shown, because the lookup already finished.
+4. Compare with the same page without the hint. Remember that DNS caching at several levels can hide the difference on a second visit, so clear the cache or use a test tool that starts fresh, such as WebPageTest.
+5. Check that you have not hinted any host the page never uses.
+
+## Best Practices
+
+1. **Hint third-party hosts you may use,** not your own.
+2. **Use origins only.**
+3. **Pair it with `preconnect`** for hosts that matter most.
+4. **Keep the list short.**
+5. **Remove hints** when you stop using a service.
+6. **Do not build hints from untrusted input,** such as user-submitted links.
+7. **Test on a fresh cache** and a slow connection.
+8. **Measure.** A hint that does not move a number is clutter.
+
+## Quick Checklist
+
+- [ ] Every hinted host is used by the page, or likely to be
+- [ ] No hint for your own site
+- [ ] Each hint is an origin, with no path
+- [ ] Hosts needed immediately use `preconnect`, with `dns-prefetch` as a fallback
+- [ ] No hosts that need consent are hinted before consent
+- [ ] Old services have had their hints removed
+- [ ] DevTools shows the DNS time dropped
+
+## Security and Privacy Notes
+
+- **A lookup tells the network something.** When your page asks for a lookup, the visitor's DNS resolver (often their internet provider) learns that this page uses that host. A hint triggers the lookup earlier, and for hosts the visitor may never actually use. If you need consent before contacting certain third parties (analytics or advertising, for example), do not hint those hosts until consent is given. This is not legal advice, so check the rules that apply to you.
+- **Never create hints from untrusted input.** If a page turns a user-submitted link into a `dns-prefetch`, the visitor's browser looks up a host chosen by someone else, which can be used to track visitors. Generate hints only from a list you control.
+- **Only hint hosts you trust.** Even a lookup is a small way of reaching out.
+- **Encrypted DNS** (offered by some browsers and providers) hides lookups from people on the network, but not from the resolver. It is the visitor's choice, not something your HTML controls.
+
+## Global Audience Notes
+
+- **DNS speed varies a lot by country, provider, and network.** Visitors on slow or distant networks may see lookups of hundreds of milliseconds, so they gain most from an early lookup.
+- **Third-party hosts can be slow, or blocked, in some places.** A page must still work if a host never answers, so never make the page depend on a hinted service.
+- **Mobile networks pay a price for every lookup,** in time and battery. A short list is kind to them.
+- **Test from different regions,** using a tool such as WebPageTest, since DNS behaviour differs around the world.
+
+## Common Mistakes to Avoid
+
+1. **Hinting your own site.**
+2. **Including a path** and thinking it matters.
+3. **Hinting dozens of hosts.**
+4. **Hinting hosts the page never uses.**
+5. **Using `dns-prefetch` for a host needed straight away** when `preconnect` would save more.
+6. **Hinting before consent** for services that need it.
+7. **Building hints from user input.**
+8. **Leaving hints for services you stopped using.**
+9. **Adding `crossorigin`,** which is not needed for DNS lookups.
+10. **Assuming it always helps,** without testing on a fresh cache.
+
+## Practice Time
+
+1. In the Connection Lab, use the "Far or slow" preset. How much does `dns-prefetch` save? How much does `preconnect` save?
+2. Set "the page first needs this host at" to 200 ms or less. Why does no hint help any more? Then slowly raise it, and watch each hint start to save time.
+3. Sort the hosts. Which one surprised you?
+4. List every third-party host on a page you built, using the Network panel.
+5. Decide which need `preconnect`, which need `dns-prefetch`, and which need nothing.
+6. Add the hints, and check the **DNS Lookup** time in the Timing tab.
+7. Remove a hint for a host the page no longer uses.
+8. Bonus: run WebPageTest on your page and look at the connection view.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What does `dns-prefetch` do?
+
+It asks the browser to look up a host's address early, so that step is already done when the page needs the host. It does nothing else.
+
+
+
+
+2. What does `preconnect` add?
+
+It also opens the connection and finishes the security handshake, so more of the setup is done in advance. It costs a little more, because the connection stays open.
+
+
+
+
+3. Which hosts deserve `dns-prefetch`?
+
+Third-party hosts the page may need later, such as analytics, chat widgets, and embedded media. Not your own site.
+
+
+
+
+4. Why pair `dns-prefetch` with `preconnect`?
+
+It is a safety net: browsers that do not support `preconnect`, or that limit early connections, can still do the lookup.
+
+
+
+
+5. Do you need `crossorigin` on `dns-prefetch`?
+
+No. The lookup is the same whichever mode the files are fetched in. (`preconnect` is different, and may need it.)
+
+
+
+
+6. What privacy risk does it carry?
+
+It triggers lookups, which tell the visitor's DNS resolver about the hosts your page uses, and may contact services before consent. Never build hints from untrusted input.
+
+
+
+## Key Takeaways
+
+- **DNS turns a host name into an address,** and it takes time for each new host.
+- **`dns-prefetch` does just that step, early.** It is cheap, and saves less.
+- **Use it for third-party hosts you may need,** and `preconnect` for those you need at once.
+- **Origins only, no `crossorigin`.**
+- **Keep the list short,** and remove hints you no longer need.
+- **Mind privacy:** wait for consent where it is needed, and never hint untrusted hosts.
+- **Measure** the DNS time in DevTools, on a fresh cache.
+
+Next up: [Preconnect](./preconnect), the fuller hint that opens the whole connection early.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/html-performance-basics.mdx b/tutorials/html/15-performance/html-performance-basics.mdx
index e69de29bb..e97c83fd5 100644
--- a/tutorials/html/15-performance/html-performance-basics.mdx
+++ b/tutorials/html/15-performance/html-performance-basics.mdx
@@ -0,0 +1,663 @@
+---
+id: html-performance-basics
+title: "HTML Performance Basics"
+sidebar_label: "HTML Performance Basics"
+sidebar_position: 2
+slug: /html/performance/html-performance-basics
+description: "Learn the HTML habits behind a fast page: keep the head light, never block on scripts, size and lazy-load images, and ask four simple questions about every file. Includes a live page checker."
+keywords:
+ - HTML performance basics
+ - page speed for beginners
+ - render blocking CSS
+ - defer scripts
+ - image width and height
+ - lazy loading images
+ - layout shift
+ - fast HTML
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, page-speed, images, scripts, frontend]
+---
+
+import {useState} from 'react';
+import BrowserOnly from '@docusaurus/BrowserOnly';
+
+export const perfSamples = {
+ messy: [
+ '',
+ '',
+ '',
+ ' ',
+ ' ',
+ ' The Bread Bin',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ '',
+ '',
+ ' 
',
+ ' 
',
+ ' 
',
+ ' ',
+ '',
+ ''
+ ].join("\n"),
+ fixed: [
+ '',
+ '',
+ '',
+ ' ',
+ ' ',
+ ' The Bread Bin',
+ ' ',
+ ' ',
+ '',
+ '',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ '',
+ ''
+ ].join("\n")
+};
+
+export function auditPerformance(html) {
+ const doc = new DOMParser().parseFromString(html, "text/html");
+ const out = [];
+ const add = (level, text) => out.push({level, text});
+ const headScripts = Array.from(doc.head.querySelectorAll("script[src]"));
+ const blocking = headScripts.filter(function (s) {
+ return !s.hasAttribute("defer") && !s.hasAttribute("async") && s.getAttribute("type") !== "module";
+ });
+ if (blocking.length > 0) {
+ add("problem", blocking.length + " script(s) in the head block the page. Add defer or async.");
+ } else if (headScripts.length > 0) {
+ add("good", "Every script in the head uses defer, async or type=module.");
+ }
+ const styles = Array.from(doc.querySelectorAll("style")).map(function (s) { return s.textContent; }).join("\n");
+ if (/@import/i.test(styles)) {
+ add("problem", "A style block uses @import. The browser finds the second file only after the first arrives, so use a link element instead.");
+ }
+ const sheets = doc.querySelectorAll('link[rel~="stylesheet"]');
+ if (sheets.length > 3) {
+ add("tip", sheets.length + " separate stylesheet files. Each one is a request that can hold up the first paint, so combine or trim them where you can.");
+ } else if (sheets.length > 0) {
+ add("good", "A small number of stylesheets (" + sheets.length + ").");
+ }
+ const imgs = Array.from(doc.querySelectorAll("img"));
+ if (imgs.length > 0 && imgs[0].getAttribute("loading") === "lazy") {
+ add("problem", "The first image is lazy-loaded. If it is on the first screen, remove loading=lazy so it starts early.");
+ }
+ const noSize = imgs.filter(function (i) { return !i.hasAttribute("width") || !i.hasAttribute("height"); });
+ if (noSize.length > 0) {
+ add("problem", noSize.length + " image(s) have no width and height, so the layout can jump when they arrive.");
+ } else if (imgs.length > 0) {
+ add("good", "Every image has width and height.");
+ }
+ const lazyCandidates = imgs.slice(1).filter(function (i) { return i.getAttribute("loading") !== "lazy"; });
+ if (lazyCandidates.length > 0) {
+ add("tip", lazyCandidates.length + " later image(s) could use loading=lazy if they sit below the first screen.");
+ }
+ const frames = Array.from(doc.querySelectorAll("iframe"));
+ const eagerFrames = frames.filter(function (f) { return f.getAttribute("loading") !== "lazy"; });
+ if (eagerFrames.length > 0) {
+ add("tip", eagerFrames.length + " iframe(s) load straight away. If they are below the first screen, add loading=lazy.");
+ }
+ const frameNoSize = frames.filter(function (f) { return !f.hasAttribute("width") || !f.hasAttribute("height"); });
+ if (frameNoSize.length > 0) {
+ add("problem", frameNoSize.length + " iframe(s) have no width and height, so the page can jump when they load.");
+ }
+ if (out.length === 0) add("good", "Nothing to check here. Paste a page with a head, images or scripts.");
+ return out;
+}
+
+export function PerfCheckerInner() {
+ const [html, setHtml] = useState(perfSamples.messy);
+ const results = auditPerformance(html);
+ const problems = results.filter(function (r) { return r.level === "problem"; }).length;
+ const colors = {problem: "#c0392b", tip: "#b9770e", good: "#1e8449"};
+ const labels = {problem: "Problem", tip: "Tip", good: "Good"};
+ return (
+
+
+
+
+
+
+
+
+ {problems === 0 ? "No problems found." : problems + " problem(s) found."}
+
+
+ {results.map(function (r, i) {
+ return (
+ -
+ {labels[r.level]}:
+ {r.text}
+
+ );
+ })}
+
+
+ This is a teaching checker. It reads the HTML you paste and looks for a few common habits. It cannot measure real speed, so always confirm with a tool like Lighthouse.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The screen needs about {r.needed}px of width.{" "}
+ {r.blurry
+ ? "Your file is smaller than that, so the image will look soft on this screen."
+ : "About " + r.wastedPercent + "% of the file's pixels are never used on this screen."}
+
+
+ File size does not track pixels exactly, because it also depends on the format and the picture, but more pixels almost always means more bytes.
+
+
',
+ question: "What can go wrong?",
+ options: [
+ "The alt text is too short",
+ "The image will not load",
+ "The browser does not know the space it needs, so the layout can jump"
+ ],
+ answer: 2,
+ why: "Without width and height the browser reserves no space, so text moves down when the image arrives. Giving both lets it hold the right amount of room."
+ },
+ {
+ code: '\n
',
+ question: "What is wasteful here?",
+ options: [
+ "It downloads far more pixels than a 400px slot can show",
+ "The height is too small",
+ "JPEG is not allowed on the web"
+ ],
+ answer: 0,
+ why: "A 400px slot, even on a 2x screen, needs about 800px of width. A responsive image with several sizes lets each device download only what it needs."
+ },
+ {
+ code: '',
+ question: "Why is this slower than a link element?",
+ options: [
+ "Style blocks are not allowed",
+ "The browser only discovers the second file after the first one arrives",
+ "It makes the text bold"
+ ],
+ answer: 1,
+ why: "An @import creates a chain: the browser must fetch and read one file before it knows about the next. A link element in the head lets it find the file straight away."
+ },
+ {
+ code: '\n',
+ question: "What is a good improvement?",
+ options: [
+ "Remove the title",
+ "Add loading=\"lazy\" so it loads when the visitor gets near it",
+ "Move it to the top of the page"
+ ],
+ answer: 1,
+ why: "Embeds can be heavy, and each one brings its own files. If it is not on the first screen, loading=lazy keeps it from competing with the content people see first."
+ }
+];
+
+export function SpotQuiz() {
+ const [picked, setPicked] = useState({});
+ const done = Object.keys(picked).length;
+ const correct = spotItems.filter(function (item, i) { return picked[i] === item.answer; }).length;
+ return (
+
+
+ Answered {done} of {spotItems.length}. Correct: {correct}.
+
+ {spotItems.map(function (item, i) {
+ const chosen = picked[i];
+ const answered = chosen !== undefined;
+ return (
+
+
{item.code}
+
+ {answered ? (
+
+ {chosen === item.answer ? "Right. " : "Not quite. "}
+ {item.why}
+
+ ) : null}
+
+ );
+ })}
+ {done > 0 ? (
+
+ ) : null}
+
+
+## The Big Idea
+
+Compare two versions of the same page. They look identical to a visitor, but the browser has a very different afternoon.
+
+
+
+
+```html title="slow.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+
+```html title="fast.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+Load the slow page into the checker, then fix the problems one at a time and watch the list shrink. The `fetchpriority` attribute is a hint that the main image matters most, and it is supported in current major browsers, but check [MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority) for the latest support.
+
+## Four Questions for Every File
+
+Before you add anything to a page, ask these four questions. They cover most performance decisions.
+
+1. **Do I need it?** The fastest file is the one you never send. Unused scripts, extra fonts, and old widgets all cost something.
+2. **Is it small?** Compress images, choose the right size, and trim what you do not use.
+3. **Is it found early?** Important files should be easy for the browser to discover, ideally right in the HTML.
+4. **Does it block?** If the visitor has to wait for the file before seeing anything, ask whether it really must come first.
+
+Keep these in your head as you read the rest of the lesson. Every tip below answers one of them.
+
+## Stylesheets: Needed Before Painting
+
+A browser will not paint a page until it has the styles that apply to it, because painting unstyled content and then restyling it looks broken. So CSS in the head is **render-blocking**: it holds up the first paint until it has downloaded and been read.
+
+That is usually the right trade, but it means your CSS is on the critical path. Keep it light:
+
+| Habit | Why it helps | Watch out for |
+| :-- | :-- | :-- |
+| Send only the CSS the page uses | Less to download and read | Huge frameworks used for three rules |
+| Avoid `@import` inside CSS or style blocks | The browser finds the next file only after the first arrives | Chains of files three or four deep |
+| Use a `link` element in the head | The browser sees the file straight away | Putting a stylesheet link deep in the body |
+| Keep the number of files reasonable | Each file is a request that can delay painting | Many tiny files, or one giant file |
+
+You will read more about what counts as critical in [Critical Resources](./critical-resources). For now, remember that CSS is on the path to your first paint, so treat it with care.
+
+:::tip
+The number of files matters less than it used to, because modern servers can send several at once. Total size and the chains between files matter more.
+:::
+
+## Scripts: Do Not Block
+
+A plain `script` tag with a `src` is the most common cause of a slow first paint. The browser stops reading the HTML, downloads the script, runs it, and only then carries on.
+
+```html
+
+
+
+
+
+
+
+
+```
+
+A simple rule to start with: **use `defer` for your own scripts, and `async` for independent ones such as analytics.** Modern module scripts (`type="module"`) are deferred by default. The next lessons, [Script Loading](./script-loading), [Defer](./defer), and [Async](./async), go into the differences in detail. The original [script element lesson](/tutorials/html/html-head/script) covers the basics of the tag itself.
+
+:::warning
+Adding `defer` can break a script that expects to run before the page is ready, or that relies on another script running first. Test after the change. `defer` scripts keep their order, which helps with dependencies.
+:::
+
+## Images: The Biggest Files
+
+On most pages, images are the heaviest files, and they cause the most visible problems. Four habits cover most of them.
+
+### 1. Always give width and height
+
+```html
+
+```
+
+These two attributes let the browser work out the shape of the image before it arrives, and reserve that space. Without them, text jumps down when the image appears. That jump is what **Cumulative Layout Shift (CLS)** measures. CSS can still make the image fit its container, for example with `max-width: 100%; height: auto;`.
+
+### 2. Lazy-load images below the first screen
+
+```html
+
+```
+
+`loading="lazy"` tells the browser to wait until the image is near the screen. That saves data and leaves bandwidth for what matters. It is covered in detail in the [Lazy Loading](./lazy-loading) lesson, and the older [image lazy loading lesson](/tutorials/html/images/lazy-loading).
+
+### 3. Never lazy-load the main image
+
+The big picture people see straight away should start loading as early as possible. Leave off `loading="lazy"`, and consider `fetchpriority="high"` for it. Lazy-loading it is one of the most common ways to make a page feel slower.
+
+### 4. Do not send more pixels than the screen can show
+
+A 4000px photo in a 400px slot makes the visitor download a lot of data they cannot see. Try it:
+
+
+<>
+
+
+
+
+The fix is to offer several sizes and let the browser choose, using `srcset` and `sizes`. You can read more in [Responsive Images](./responsive-images-performance), and the earlier [responsive images lesson](/tutorials/html/images/responsive-images). Modern formats such as WebP and AVIF are often smaller than JPEG at similar quality, and most current browsers support them, but test on the browsers your visitors use.
+
+## Iframes and Embeds
+
+A single embedded video, map, or social widget can bring dozens of files of its own, from servers you do not control. You cannot easily make them smaller, but you can control when they load.
+
+```html
+
+```
+
+- Add `loading="lazy"` to embeds below the first screen.
+- Give them `width` and `height`, so the page does not jump.
+- Ask whether you need the embed, or whether a simple link or a still image would do.
+- Always give an iframe a `title`, for screen reader users.
+
+## A Word About Fonts
+
+Custom fonts are files too, and a page waiting for a font may show invisible text. Two cautious habits help: use as few font files as you can, and set `font-display: swap` in your `@font-face` rule so text shows in a fallback font while the real one loads. Fonts have trade-offs (a brief change of look when they swap in), so test how it feels. We will return to what to load first in [Critical Resources](./critical-resources).
+
+## Some Speed Belongs to the Server
+
+Not everything is in your HTML. These matter just as much, and are usually set up where the site is hosted:
+
+- **Compression.** Text files (HTML, CSS, JavaScript) can be compressed with gzip or Brotli, often shrinking them a lot.
+- **Caching.** Files that do not change can be stored by the browser, so a returning visitor downloads nothing.
+- **A CDN.** A content delivery network serves files from near the visitor.
+- **A fast server response.** If the HTML itself is slow to arrive, nothing else can start.
+
+If you use a platform like Netlify, Vercel, or GitHub Pages, much of this is handled for you. Check your host's documentation to see what is on by default.
+
+## Spot the Slowdown
+
+Time to practise. Each snippet has one problem, or one improvement waiting to happen. Pick an answer to see why.
+
+
+<>
+
+
+
+
+
+
+
+## Best Practices
+
+1. **Measure first.** Use Lighthouse or DevTools to find the real problem before guessing.
+2. **Keep the head light.** A few small stylesheets, scripts with `defer` or `async`, and nothing else you do not need.
+3. **Give every image and iframe `width` and `height`.**
+4. **Lazy-load below the first screen, and never the main image.**
+5. **Serve images at the size they are shown,** and consider modern formats.
+6. **Remove what you do not use.** Old scripts, unused styles, and spare fonts all cost something.
+7. **Test on a slow connection and a modest phone,** not only your own fast machine.
+
+## Quick Checklist
+
+- [ ] No plain scripts in the head
+- [ ] No `@import` chains for CSS
+- [ ] Every image and iframe has `width` and `height`
+- [ ] The main image is not lazy-loaded
+- [ ] Images below the first screen use `loading="lazy"`
+- [ ] No image is much larger than the space it fills
+- [ ] Embeds are lazy-loaded, or replaced by a link
+- [ ] Compression and caching are on at the server
+
+## Security and Privacy Notes
+
+- **Every script is trust.** A script you load from another site runs with the full power of your page. Add only scripts you need, from providers you trust. For files that never change, the `integrity` attribute lets the browser check that the file has not been altered.
+- **Embeds can track visitors.** Maps, videos, and social widgets may set cookies or collect data as soon as they load. Lazy-loading them can reduce this on pages where visitors never scroll that far, but do not rely on it for consent. Check the rules that apply to you.
+- **Do not cache private pages in shared caches.** Pages with personal information need the right cache headers. Your host's documentation explains the options.
+- **Keep the page working without extras.** A page that depends on a third-party script to show its main content is both slow and fragile if that script is blocked or fails.
+
+## Global Audience Notes
+
+- **Many visitors use slow networks and modest phones.** A page that is fast for them is fast for everyone.
+- **Data can be expensive.** Large images, autoplaying media, and heavy embeds can cost visitors real money. Lazy loading and right-sized images are kind to people on limited plans.
+- **Distance adds delay.** A CDN is one of the easiest wins for a worldwide audience.
+- **Fonts for some scripts are large.** Chinese, Japanese, and Korean fonts can be very big, so use subsets or system fonts where you can.
+- **Some third-party services are slow or blocked in some places.** A page should still load if one of them does not.
+
+## Common Mistakes to Avoid
+
+1. **Plain `script` tags in the head,** which block the page.
+2. **Lazy-loading the main image.**
+3. **Images with no `width` and `height`,** so the layout jumps.
+4. **Huge images in small slots.**
+5. **`@import` chains in CSS.**
+6. **Loading every font weight "just in case".**
+7. **Embeds above the fold that nobody needs.**
+8. **Adding `defer` without testing,** then breaking a script that needed to run early.
+9. **Trusting one test on a fast laptop.**
+10. **Adding hints and tricks before fixing the basics.**
+
+## Practice Time
+
+1. Paste a page you built into the checker. How many problems does it find?
+2. Fix every problem it reports, one at a time.
+3. Use the image lab to find a file width that wastes less than 25% of its pixels on a 2x screen at 400px.
+4. Take the Spot the Slowdown quiz. Which one surprised you?
+5. Open DevTools, then the Network panel, and reload one of your pages. Which file is the biggest?
+6. Add `width` and `height` to every image on a page, then reload with a slow connection. Does the layout still jump?
+7. Add `defer` to a script, and check that your page still works.
+8. Bonus: run Lighthouse before and after your changes, and compare the results.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What four questions should you ask about every file?
+
+Do I need it? Is it small? Is it found early? Does it block?
+
+
+
+
+2. Why is a plain script in the head a problem?
+
+The browser stops reading the HTML to download and run it, which delays everything after it. Use `defer` or `async` instead.
+
+
+
+
+3. Why give images `width` and `height`?
+
+So the browser can reserve the right space before the image arrives. That stops the layout from jumping, which is what CLS measures.
+
+
+
+
+4. Which images should use `loading="lazy"`?
+
+Images below the first screen. The main image should not, because lazy loading delays it.
+
+
+
+
+5. Why avoid `@import` in CSS?
+
+The browser only discovers the imported file after it has fetched and read the first one, which creates a chain of delays. A `link` element lets it find the file straight away.
+
+
+
+
+6. Name two speed jobs that belong to the server.
+
+Compression (such as gzip or Brotli) and caching. A CDN and a fast server response also matter.
+
+
+
+## Key Takeaways
+
+- **A page is a shopping list of files.** Make it short, small, early, and non-blocking.
+- **CSS in the head blocks painting,** so keep it light.
+- **Use `defer` and `async`** so scripts do not stop the page.
+- **Always size images and iframes,** and lazy-load those below the first screen.
+- **Never lazy-load the main image.**
+- **Send the right number of pixels,** not more than the screen can show.
+- **Some speed is the server's job:** compression, caching, and a CDN.
+- **Measure, change one thing, and measure again.**
+
+Next up: [Resource Hints](./resource-hints), where you will learn how to tell the browser about files before it finds them.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/index.mdx b/tutorials/html/15-performance/index.mdx
index 124dc3dac..8419b0efc 100644
--- a/tutorials/html/15-performance/index.mdx
+++ b/tutorials/html/15-performance/index.mdx
@@ -328,116 +328,8 @@ The lessons in this section each add a tool. Match them to the problems they sol
## What Is in This Section
-### Foundations
-
-
-
-
-
HTML Performance Basics
-
What makes pages slow, and the HTML habits that make them fast.
-
-
-
-
-
-
Critical Resources
-
Finding the few files that must arrive first, and putting them first.
-
-
-
-
-
-
Core Web Vitals
-
LCP, INP, and CLS: what they measure, and how to improve them.
-
-
-
-
-
-
-
Resource Hints
-
How preload, prefetch, preconnect, and dns-prefetch differ.
-
-
-
-
-
-
Preload
-
Fetching a file you know the page needs, earlier than the browser would.
-
-
-
-
-
-
Prefetch
-
Quietly fetching what the next page will need.
-
-
-
-
-
-
DNS Prefetch
-
Looking up another site's address ahead of time.
-
-
-
-
-
-
Preconnect
-
Opening a connection to another origin before you need it.
-
-
-
-
-
-
-
Script Loading
-
How classic, module, defer, and async scripts affect the page.
-
-
-
-
-
-
defer
-
Download early, run after the page is parsed, in order.
-
-
-
-
-
-
async
-
Download early, run as soon as ready, in any order.
-
-
-
-
-
-
-
Lazy Loading
-
Waiting to load images and frames until they are needed.
-
-
-
-
-
-
Responsive Images and Performance
-
Sending each device an image of the right size.
-
-
-
-
+
+
+
+
+
+
+
+ {r.items.map(function (it) {
+ return (
+
+ {it.index === 0 ? "Hero" : "Img " + it.index}
+
+ );
+ })}
+
+
+ Loaded {r.loaded} of {r.total} images, about {r.kb} KB of {r.totalKb} KB.
+
+ {mode === "lazy" ? (
+
+ The hero is lazy too. The browser waits until it has laid out the page before it starts that download, so the biggest thing on the screen arrives later than it needed to.
+
+ ) : null}
+
+
+ This is a simplified model: twelve images 600 px apart, a 800 px screen, and images loading once they are within 1000 px of it. Real browsers pick their own distance, and it can depend on the connection.
+
+
![Rye loaves]()
',
+ ' ',
+ ' 
',
+ ' 
',
+ ' 
',
+ ' ',
+ ' ',
+ ''
+ ].join("\n"),
+ fixed: [
+ '',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ' ',
+ ''
+ ].join("\n")
+};
+
+export function auditLazy(html) {
+ const doc = new DOMParser().parseFromString(html, "text/html");
+ const out = [];
+ const add = (level, text) => out.push({level: level, text: text});
+ const imgs = Array.from(doc.querySelectorAll("img")).filter(function (i) { return !i.closest("noscript"); });
+ const frames = Array.from(doc.querySelectorAll("iframe"));
+ const isLazy = function (el) { return (el.getAttribute("loading") || "").toLowerCase() === "lazy"; };
+ if (imgs.length > 0 && isLazy(imgs[0])) {
+ add("problem", "The first image is lazy-loaded. If it is on the first screen, remove loading=lazy so it starts early.");
+ }
+ const jsOnly = imgs.filter(function (i) { return !i.hasAttribute("src") && (i.hasAttribute("data-src") || i.hasAttribute("data-srcset")); });
+ if (jsOnly.length > 0) {
+ const hasNoscript = doc.querySelectorAll("noscript img").length > 0;
+ add(hasNoscript ? "tip" : "problem", jsOnly.length + " image(s) have no src and depend on JavaScript. " + (hasNoscript ? "You have a noscript fallback, which helps." : "Without JavaScript, or if the script fails, nothing shows. Prefer native loading=lazy with a real src."));
+ }
+ const all = imgs.concat(frames);
+ const badValue = all.filter(function (el) {
+ return el.hasAttribute("loading") && ["lazy", "eager"].indexOf(el.getAttribute("loading").toLowerCase()) === -1;
+ });
+ if (badValue.length > 0) add("problem", badValue.length + " element(s) have a loading value that is not lazy or eager, so it is ignored.");
+ const lazyNoSize = all.filter(function (el) { return isLazy(el) && (!el.hasAttribute("width") || !el.hasAttribute("height")); });
+ if (lazyNoSize.length > 0) add("problem", lazyNoSize.length + " lazy element(s) have no width and height, so the layout will jump as they load in.");
+ const hidden = all.filter(function (el) { return isLazy(el) && /display\s*:\s*none/i.test(el.getAttribute("style") || ""); });
+ if (hidden.length > 0) add("tip", hidden.length + " lazy element(s) are hidden with display:none. Hidden images may never load, or may load late when shown.");
+ const redundant = all.filter(function (el) { return (el.getAttribute("loading") || "").toLowerCase() === "eager"; });
+ if (redundant.length > 0) add("tip", redundant.length + " element(s) use loading=eager, which is already the default. It does no harm, but you can remove it.");
+ const eagerFrames = frames.filter(function (f) { return !isLazy(f); });
+ if (eagerFrames.length > 0) add("tip", eagerFrames.length + " iframe(s) load straight away. If they are below the first screen, add loading=lazy.");
+ const videos = Array.from(doc.querySelectorAll("video")).filter(function (v) { return !v.hasAttribute("preload"); });
+ if (videos.length > 0) add("tip", videos.length + " video(s) have no preload attribute. For videos below the first screen, preload=\"none\" or \"metadata\" with a poster image avoids a big early download.");
+ const laterLazy = imgs.slice(1).filter(isLazy);
+ if (laterLazy.length > 0) add("good", laterLazy.length + " later image(s) use loading=lazy.");
+ if (out.length === 0) add("good", "Nothing to flag. Paste a page with images, iframes, or videos.");
+ return out;
+}
+
+export function LazyAuditInner() {
+ const [html, setHtml] = useState(lazySamples.messy);
+ const results = auditLazy(html);
+ const problems = results.filter(function (r) { return r.level === "problem"; }).length;
+ const colors = {problem: "#c0392b", tip: "#b9770e", good: "#1e8449"};
+ const labels = {problem: "Problem", tip: "Tip", good: "Good"};
+ return (
+
+
+
+
+
+
+
+
+ {problems === 0 ? "No problems found." : problems + " problem(s) found."}
+
+
+ {results.map(function (r, i) {
+ return (
+ -
+ {labels[r.level]}:
+ {r.text}
+
+ );
+ })}
+
+
+ This is a teaching checker. It reads markup only, so it cannot know which images are on the first screen. You decide that, then confirm with DevTools.
+
+
+
+## The Big Idea
+
+For most pages, the rule is short: **do not lazy-load what is on the first screen, and lazy-load most of what is not.**
+
+
+
+
+```html title="index.html"
+
+
+
+
+
+
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the lab, compare the three strategies at the top of the page without scrolling. Then scroll down and watch what each one has downloaded. Loading everything wastes data. Making the hero lazy delays the one image people see first. The smart option does neither.
+
+## What to Lazy-Load
+
+| Element | Lazy-load? | Why |
+| :-- | :-- | :-- |
+| The main image on the first screen | No | It is usually your Largest Contentful Paint, and should start early |
+| Logo and header images | No | They are visible at once |
+| Images below the first screen | Yes | Many visitors never reach them |
+| Iframes (maps, videos, widgets) below the first screen | Yes | They are heavy and bring their own files |
+| Images in a closed tab, menu, or accordion | Usually yes | They are not seen until opened |
+| Videos below the first screen | Use `preload` | See below |
+| CSS background images | Use a script | The `loading` attribute does not apply |
+
+:::tip
+If you are not sure whether something is on the first screen, check it at a few common screen sizes. A tall hero on a phone may push the second image off the screen, while on a wide monitor it might be visible at once.
+:::
+
+## Lazy Loading Is Not Free
+
+Lazy loading can cause its own problems if you are careless:
+
+1. **Delay for what is visible.** A lazy image waits for the browser to lay out the page before it starts. For the main image, that is a delay you do not want.
+2. **Layout jumps.** An image with no `width` and `height` has no size until it arrives, so the page shifts as the visitor scrolls. This hurts your Cumulative Layout Shift (CLS).
+3. **Blank spaces.** If the visitor scrolls fast on a slow connection, they may reach an image before it has loaded. Browsers start the download before the image reaches the screen, but on a slow network it may still show a gap.
+4. **Hidden content.** Images that are never shown, such as those in `display: none` areas, may never load.
+
+The fixes are simple: leave the first-screen images alone, always give images and iframes a `width` and `height`, and use a placeholder colour or a reserved shape so the gap looks intentional.
+
+## Reserve the Space
+
+An image that has `width` and `height` lets the browser reserve the right room before it arrives. CSS can still make it fit its container:
+
+```css
+img {
+ max-width: 100%;
+ height: auto;
+}
+```
+
+For a box with no image yet, such as an embed or a CSS background, you can reserve space with `aspect-ratio`:
+
+```css
+.video-box {
+ aspect-ratio: 16 / 9;
+ background: #eee;
+}
+```
+
+## Videos and Iframes
+
+Native lazy loading works for `img` and `iframe`. A `video` element has no `loading` attribute, but you can control how much it downloads up front:
+
+```html
+
+```
+
+- `preload="none"` downloads no video data until the visitor plays it.
+- `preload="metadata"` fetches just enough to show the length and first frame.
+- A `poster` image shows something useful while the video waits.
+
+## Click to Load: A Kind Way to Embed
+
+A video or map embed can pull in dozens of files, and may contact third-party servers, before anyone has pressed play. A "click to load" pattern (sometimes called a facade) shows a simple picture and button, and loads the real embed only when the visitor asks:
+
+```html
+
+```
+
+```js
+document.querySelectorAll(".video-facade").forEach(function (btn) {
+ btn.addEventListener("click", function () {
+ const frame = document.createElement("iframe");
+ frame.src = btn.dataset.embed;
+ frame.width = 560;
+ frame.height = 315;
+ frame.title = "The story of our bakery";
+ frame.allow = "autoplay; fullscreen";
+ btn.replaceWith(frame);
+ }, { once: true });
+});
+```
+
+This saves data and time for everyone who does not press play, and it is also good for privacy, because no third party is contacted until the visitor chooses. Make sure the button has an accessible name (here, the visible text does the job).
+
+## Lazy-Loading CSS Backgrounds
+
+The `loading` attribute does not apply to CSS backgrounds. A small script using `IntersectionObserver` can add the image when the element gets near the screen:
+
+```html
+
+```
+
+```js
+const io = new IntersectionObserver(function (entries, observer) {
+ entries.forEach(function (entry) {
+ if (!entry.isIntersecting) return;
+ entry.target.style.backgroundImage = "url(" + entry.target.dataset.bg + ")";
+ observer.unobserve(entry.target);
+ });
+}, { rootMargin: "300px" });
+
+document.querySelectorAll(".lazy-bg").forEach(function (el) { io.observe(el); });
+```
+
+The `rootMargin` starts the load a little before the element is on screen. This approach needs JavaScript, so choose it only for decorative backgrounds, and give the element a plain background colour as a fallback. For important images, a real `img` with `loading="lazy"` is simpler and more robust.
+
+## A Note on Search Engines
+
+Search engines generally handle the native `loading="lazy"` attribute well, because the image has a real `src` in the HTML. Patterns that leave the `src` empty and fill it in with JavaScript are riskier, since the crawler needs to run your script to see the image. Prefer native lazy loading, and check any important images with a tool such as Search Console's URL inspection. The [HTML SEO Basics lesson](/tutorials/html/seo/html-seo-basics) has more.
+
+## Audit a Page
+
+Load the messy page below and fix each problem, one at a time.
+
+
+<>
+
+
+
+
+## Checking in DevTools
+
+1. Open DevTools, then **Network**, and filter by **Img**.
+2. Reload without scrolling. Only images near the first screen should load.
+3. Scroll down slowly. New images should appear in the list just before they reach the screen.
+4. Look at the first screen's main image. It should start early and **not** be lazy.
+5. Throttle the network to a slow setting, and scroll quickly. Do gaps appear? If so, consider a larger margin or a placeholder.
+6. Run Lighthouse and check your LCP and CLS before and after.
+
+## Best Practices
+
+1. **Never lazy-load the main image or anything on the first screen.**
+2. **Lazy-load images and iframes below the first screen.**
+3. **Always give `width` and `height`.**
+4. **Use native `loading="lazy"` first,** and a script only where it cannot work.
+5. **Use `preload="none"` or `"metadata"`** and a `poster` for videos below the first screen.
+6. **Use click-to-load** for heavy embeds.
+7. **Keep a real `src`** in the HTML, so the page works without JavaScript.
+8. **Test with a slow connection and a fast scroll.**
+
+## Quick Checklist
+
+- [ ] The first-screen images are not lazy
+- [ ] Later images and iframes use `loading="lazy"`
+- [ ] Every image and iframe has `width` and `height`
+- [ ] Images keep a real `src` in the HTML
+- [ ] Videos use `preload` and a `poster`
+- [ ] Heavy embeds load on click, if they are not essential
+- [ ] DevTools shows only nearby images loading on a fresh load
+- [ ] LCP and CLS are checked before and after
+
+## Security and Privacy Notes
+
+- **Lazy loading is not a privacy tool by itself.** A lazy third-party iframe still contacts its host when the visitor scrolls near it, and visitors may scroll without choosing to interact. For services that need consent, or that track visitors, use a click-to-load pattern, or wait for consent before adding the embed. This is not legal advice, so check the rules that apply to you.
+- **Trust what you embed.** An iframe runs another site inside yours. Use only hosts you trust, and consider the `sandbox` attribute for untrusted content.
+- **Do not put private data in image URLs.** Lazy-loaded URLs are visible in the page source and may be logged.
+- **Do not hide important content behind a script.** If the lazy-loading script fails or is blocked, the page should still show its important images.
+
+## Global Audience Notes
+
+- **Lazy loading saves the most for people on limited data.** On pay-as-you-go plans, every skipped image is money saved.
+- **Slow networks make gaps more obvious.** Use placeholders and a modest margin so scrolling feels smooth.
+- **Fast scrollers and older devices** may reach images before they load. Test on a modest phone.
+- **Layouts that run right to left** behave the same way, since lazy loading depends on vertical position. Check that placeholders and reserved space look right in your own language.
+- **Images carry meaning.** Always give lazy images useful `alt` text, so they are understood even before or without loading.
+
+## Common Mistakes to Avoid
+
+1. **Lazy-loading the main image.**
+2. **Lazy images with no `width` and `height`.**
+3. **Every image lazy,** including the logo.
+4. **An empty `src` that depends on JavaScript.**
+5. **Writing `loading="true"`** or another value that is not `lazy` or `eager`.
+6. **Lazy-loading hidden images** and expecting them to load when shown.
+7. **Heavy embeds loading straight away** when a facade would do.
+8. **Videos with no `preload` and no `poster`.**
+9. **Testing only on a fast connection,** and missing the gaps.
+10. **Not checking LCP and CLS** after the change.
+
+## Practice Time
+
+1. In the Scroll Lab, at the top of the page, two strategies download the same amount. Which two, and why is one of them still worse for the visitor?
+2. Scroll to the bottom with each strategy. How do the totals compare?
+3. Load the messy page in the auditor. Fix every problem it reports.
+4. Open a page you built, and filter the Network panel by **Img**. Which images load before you scroll?
+5. Add `loading="lazy"` to the ones below the first screen, and reload.
+6. Add `width` and `height` to every image, and check there is no jump.
+7. Replace one iframe with a click-to-load button.
+8. Bonus: run Lighthouse before and after, and compare LCP and CLS.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What does lazy loading do?
+
+It delays loading images and iframes until the visitor gets near them, saving data and speeding up the first load.
+
+
+
+
+2. Which images should never be lazy-loaded?
+
+The main image and anything else on the first screen. Lazy loading delays them, which usually makes Largest Contentful Paint worse.
+
+
+
+
+3. How do you avoid layout jumps with lazy images?
+
+Give every image and iframe a `width` and `height`, so the browser reserves the space. For other boxes, use `aspect-ratio`.
+
+
+
+
+4. How do you lazy-load a video?
+
+Videos have no `loading` attribute. Use `preload="none"` or `"metadata"` with a `poster` image, or a click-to-load pattern.
+
+
+
+
+5. What about CSS background images?
+
+The `loading` attribute does not apply. Use `IntersectionObserver` in a small script, and keep the approach for decorative images.
+
+
+
+
+6. Why is click-to-load good for privacy?
+
+No third-party server is contacted until the visitor chooses to play or load the embed.
+
+
+
+## Key Takeaways
+
+- **Lazy loading waits.** It spares the visitor from downloading what they may never see.
+- **First screen: never lazy. Below it: usually lazy.**
+- **Always reserve space** with `width`, `height`, or `aspect-ratio`.
+- **Prefer native `loading="lazy"`,** with a real `src`.
+- **Videos use `preload` and `poster`.** Heavy embeds can load on click.
+- **Use a script only where native lazy loading cannot work.**
+- **Test on slow networks and check LCP and CLS.**
+
+Next up: [Script Loading](./script-loading), where you will learn how the browser fetches and runs your JavaScript, and how to stop it blocking the page.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/preconnect.mdx b/tutorials/html/15-performance/preconnect.mdx
new file mode 100644
index 000000000..829d1b056
--- /dev/null
+++ b/tutorials/html/15-performance/preconnect.mdx
@@ -0,0 +1,470 @@
+---
+id: html-perf-preconnect
+title: "Preconnect in HTML"
+sidebar_label: "Preconnect"
+sidebar_position: 7
+slug: /html/performance/preconnect
+description: "Learn link rel=preconnect: open the connection to an important server early. Understand why crossorigin matters, how many to use, and how to pick the right origins, with a connection lab and an origin picker."
+keywords:
+ - link rel preconnect
+ - preconnect crossorigin
+ - preconnect vs dns-prefetch
+ - third-party origins
+ - connection setup
+ - TLS handshake
+ - HTML performance
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, preconnect, resource-hints, third-party, frontend]
+---
+
+import {useState} from 'react';
+
+export const poolKinds = [
+ {id: "font", label: "A web font (@font-face)", pool: "anon"},
+ {id: "img", label: "An img tag", pool: "cred"},
+ {id: "imgc", label: "An img tag with crossorigin", pool: "anon"},
+ {id: "css", label: "A stylesheet link", pool: "cred"},
+ {id: "script", label: "A classic script tag", pool: "cred"},
+ {id: "fetch", label: "A fetch() call", pool: "anon"}
+];
+
+export function poolReady(hints, kind) {
+ return kind.pool === "cred" ? hints.plain : hints.cors;
+}
+
+export function ConnectionPoolLab() {
+ const [plain, setPlain] = useState(false);
+ const [cors, setCors] = useState(false);
+ const hints = {plain: plain, cors: cors};
+ const open = (plain ? 1 : 0) + (cors ? 1 : 0);
+ return (
+
+
+
+
+
+ | The page later asks for |
+ Result |
+
+
+
+ {poolKinds.map(function (k) {
+ const ready = poolReady(hints, k);
+ return (
+
+ | {k.label} |
+
+ {ready ? "Uses the ready connection" : "Needs a new connection"}
+ |
+
+ );
+ })}
+
+
+
+ You have {open} connection(s) opened early. Open only the kind you will really use.
+
+
+ This shows the general rule used by most browsers: requests made with credentials and requests made without them use separate connections. Details can differ between browsers, so confirm in DevTools.
+
+
+
+
+
+
+
+
+
+ {r.bad.length > 0 ? (
+
Skipped {r.bad.length} line(s) that are not full http or https URLs.
+ ) : null}
+
Origins found ({r.origins.length})
+
+ {r.origins.map(function (o, i) {
+ const value = choices[o.origin] || (o.count >= 2 ? "preconnect" : "dns-prefetch");
+ return (
+ -
+
+
+
+ );
+ })}
+
+
{out === "" ? "(no hints chosen)" : out}
+
4 ? "#b9770e" : "inherit"}}>
+ {preCount > 4 ? "You chose " + preCount + " preconnects. That is a lot. Keep them for the few origins needed in the first seconds." : "Preconnects chosen: " + preCount + "."}
+
+
+ This is a starting point. It guesses that origins used more often matter more, and that font files need crossorigin. You know your page better, so adjust each choice.
+
+
+
+## The Big Idea
+
+A preconnect names an origin (scheme and host), not a file. The browser opens a connection to it and keeps it ready.
+
+
+
+
+```html title="index.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the lab, tick one hint at a time and see which kinds of request can use it. You will notice that no single hint covers everything, which is the key idea of the next sections.
+
+## What Preconnect Does
+
+For a new `https` host, preconnect does all of the setup steps that come before a request:
+
+1. **DNS lookup**: find the server's address.
+2. **Connect**: open a line to the server.
+3. **Secure handshake**: agree on encryption.
+
+It sends **no request** for any file. The browser simply keeps the connection ready for when the page needs it. Compared with `dns-prefetch`, which only does step 1, preconnect can save much more, and costs a little more too.
+
+:::warning
+An idle connection does not stay open forever. Browsers close unused connections after a short time, so a preconnect for something the page uses much later may be wasted. The exact time varies by browser.
+:::
+
+## The `crossorigin` Question
+
+Here is the part that surprises people. Browsers keep **two separate sets** of connections to the same host: one for requests made with credentials (such as cookies) and one for requests made without. They cannot share a connection.
+
+- A plain `preconnect` (no `crossorigin`) prepares the **credentialed** connection. Images, stylesheets, and classic scripts use it.
+- A `preconnect` with `crossorigin` prepares the **anonymous** connection. Fonts, `fetch()` calls, and anything with a `crossorigin` attribute use it.
+
+If you hint the wrong one, the real request cannot use it, and the browser opens a new connection anyway. You paid for a connection nobody used.
+
+| The page later loads | Hint it needs |
+| :-- | :-- |
+| An image, stylesheet, or classic script from the host | `preconnect` (no `crossorigin`) |
+| A font, or data with `fetch()` | `preconnect` with `crossorigin` |
+| A mix of both | Both hints, one with and one without |
+
+Go back to the Connection Lab and try each combination. If a host serves both kinds, you may need both hints, but remember that each one is a connection you are paying for. Browsers differ in small details, so check in DevTools which connections are really used.
+
+## How Many Is Too Many?
+
+Each preconnect uses time, memory, and a connection on the visitor's device and on the server. Browsers may also limit how many early connections they will open. A sensible rule of thumb is to keep preconnect for **two to four** origins that the page needs in its first seconds, and use `dns-prefetch` for the rest. Lighthouse has an audit that suggests which origins are worth preconnecting and warns about having too many, but treat that as advice and test.
+
+Good candidates are:
+
+- The host that serves your **first-screen images** (a CDN, for example)
+- The host that serves your **fonts**
+- A host your **main script** calls straight away
+
+Poor candidates are anything used late, anything that needs consent first, and anything you only link to.
+
+## Pick Your Origins
+
+Paste the URLs your page loads (the Network panel in DevTools can list them), and this tool extracts the unique origins, guesses which need `crossorigin`, and writes the hints. Then adjust each choice yourself.
+
+
+<>
+
+
+
+
+## Preconnect vs DNS Prefetch
+
+| | `dns-prefetch` | `preconnect` |
+| :-- | :-- | :-- |
+| Does the DNS lookup | Yes | Yes |
+| Opens the connection and handshake | No | Yes |
+| Cost | Tiny | Small, but a connection stays open |
+| Needs `crossorigin` | No | Sometimes |
+| Best for | Hosts you may need later | Hosts you need very soon |
+
+Use them together for important hosts: `preconnect` does the work, and `dns-prefetch` is a fallback for browsers that do not support it. See the [DNS Prefetch lesson](./dns-prefetch) for the reasoning.
+
+## Preconnect from a Header or a Script
+
+Like other hints, preconnect can be sent from the server as a header:
+
+```http
+Link: ; rel=preconnect
+Link: ; rel=preconnect; crossorigin
+```
+
+You can also add it with JavaScript when the visitor shows interest, for example on hover over a button that will load a third-party widget. That keeps the cost for people who do not need it close to zero:
+
+```js
+const btn = document.querySelector("#open-chat");
+btn.addEventListener("mouseenter", function () {
+ const link = document.createElement("link");
+ link.rel = "preconnect";
+ link.href = "https://chat.example.com";
+ document.head.appendChild(link);
+}, { once: true });
+```
+
+## Checking That It Worked
+
+1. Open DevTools, then **Network**, and reload.
+2. Click a request to the hinted host and open its **Timing** tab. The **Initial connection** and **SSL** parts should be short or missing, because they happened earlier.
+3. Look at the **Waterfall** with the connection column shown, if your browser offers it. Fewer new connections means the preconnect was reused.
+4. Test on a fresh cache and a slow network, because caching and fast networks can hide the difference.
+5. Compare a key number, such as Largest Contentful Paint (LCP), before and after.
+6. If the connection is not reused, check `crossorigin` first. It is the most common cause.
+
+## Best Practices
+
+1. **Preconnect only to origins the page needs in its first seconds.**
+2. **Keep the list to a few.**
+3. **Use `crossorigin` when the files load in CORS mode,** such as fonts.
+4. **Hint the credentialed and anonymous connection separately** if the host needs both.
+5. **Add `dns-prefetch` as a fallback.**
+6. **Use origins only,** with no path.
+7. **Add it on interaction** for things that load only when asked.
+8. **Remove hints for services you no longer use,** and measure after every change.
+
+## Quick Checklist
+
+- [ ] Each preconnect is for an origin the page uses early
+- [ ] Font and `fetch()` hosts have `crossorigin`
+- [ ] No more than a few preconnects
+- [ ] `dns-prefetch` added as a fallback for the important ones
+- [ ] No hint for your own site
+- [ ] No hint for hosts that need consent first
+- [ ] DevTools shows the connection was reused
+
+## Security and Privacy Notes
+
+- **A preconnect sends no request, but it still reaches out.** The host learns the visitor's network address and some details of the secure handshake, even if the visitor never uses the service. If you need consent before contacting certain services (analytics or advertising, for example), do not hint those hosts until consent is given. This is not legal advice, so check the rules that apply to you.
+- **Only preconnect to hosts you trust.** A connection is a relationship. Never build hints from untrusted input, such as user-submitted links.
+- **Use https.** Preconnecting to a plain `http` host gives you almost nothing, and sends visitors to an unencrypted service.
+- **A broken host costs time.** If a host has a certificate error or never answers, the preconnect wastes effort, and may add warnings to the console. Make sure your page works without it.
+- **Idle connections use server resources too,** so a popular page with many preconnects can add load for the service you point at.
+
+## Global Audience Notes
+
+- **Distance makes connections expensive.** A visitor far from the server may wait several round trips for the setup, so preconnect helps most for them. A CDN with servers near visitors reduces the gap.
+- **Mobile connections are slower to set up,** and each extra connection costs battery. A short list is kind to them.
+- **Some third-party hosts are slow or blocked in some countries.** A preconnect to a host that never answers is wasted time. The page must still work if the host fails.
+- **Test from other regions** with a tool such as WebPageTest, and on a modest phone, not only your own fast machine.
+
+## Common Mistakes to Avoid
+
+1. **Forgetting `crossorigin` on font hosts.**
+2. **Adding `crossorigin` to image-only hosts,** so the real requests cannot use the connection.
+3. **Preconnecting to a dozen hosts.**
+4. **Preconnecting to hosts used late,** so the connection closes before it is used.
+5. **Preconnecting to your own site.**
+6. **Putting a path in the URL.**
+7. **Hinting before consent** for services that need it.
+8. **Leaving hints for services you removed.**
+9. **Using it instead of fixing a late-found file** that `preload` or better HTML would solve.
+10. **Never checking** that the connection was reused.
+
+## Practice Time
+
+1. In the Connection Lab, which kinds of request can use a plain `preconnect`? Which need `crossorigin`?
+2. Tick both hints. What does it cost?
+3. Open DevTools on a page you built, and list the third-party origins.
+4. Paste a few of their URLs into the origin picker, and see what it suggests.
+5. Change at least one suggestion, and say why.
+6. Add the hints, and compare the Timing tab for one request before and after.
+7. Add a `preconnect` on hover for a widget that loads on click.
+8. Bonus: run WebPageTest on your page, and look at which connections were opened, and when.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What does preconnect do?
+
+It does the DNS lookup, opens the connection, and finishes the secure handshake for an origin early, so the page's later requests can use the ready connection. It sends no request itself.
+
+
+
+
+2. How is it different from `dns-prefetch`?
+
+`dns-prefetch` only does the lookup. `preconnect` does the whole setup, so it saves more, but keeps a connection open.
+
+
+
+
+3. When is `crossorigin` needed?
+
+When the files load in CORS mode, such as fonts and `fetch()` calls. A plain preconnect and a `crossorigin` preconnect prepare two different connections, so the hint must match the later request.
+
+
+
+
+4. How many preconnects should a page have?
+
+Only a few, for the origins needed in the first seconds. Two to four is a sensible rule of thumb. Use `dns-prefetch` for the rest.
+
+
+
+
+5. Why can a preconnect be wasted?
+
+Idle connections close after a short time, so a host used late may need a new connection anyway. A hint with the wrong `crossorigin`, or for a host the page never uses, is wasted too.
+
+
+
+
+6. What privacy care does it need?
+
+It contacts a third party before the visitor does anything, which shares their network address. Wait for consent where it is needed, and never build hints from untrusted input.
+
+
+
+## Key Takeaways
+
+- **Preconnect does the connection setup early:** lookup, connect, and handshake.
+- **It names an origin, not a file,** and sends no request.
+- **`crossorigin` selects which connection you prepare.** Match it to the later request.
+- **Keep the list short:** a few early hosts, with `dns-prefetch` for the rest.
+- **Pair it with `dns-prefetch`** as a fallback.
+- **Add it on interaction** for things loaded only when asked.
+- **Respect privacy:** wait for consent, trust the host, and measure that the connection was reused.
+
+Next up: [Lazy Loading](./lazy-loading), where you will stop loading images and iframes the visitor has not reached yet.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/prefetch.mdx b/tutorials/html/15-performance/prefetch.mdx
new file mode 100644
index 000000000..f68d469ab
--- /dev/null
+++ b/tutorials/html/15-performance/prefetch.mdx
@@ -0,0 +1,435 @@
+---
+id: html-perf-prefetch
+title: "Prefetch in HTML"
+sidebar_label: "Prefetch"
+sidebar_position: 5
+slug: /html/performance/prefetch
+description: "Learn link rel=prefetch: quietly download files for the page a visitor will probably open next. See when it pays off, when it wastes data, and what must never be prefetched."
+keywords:
+ - link rel prefetch
+ - prefetch next page
+ - prefetch vs preload
+ - low priority fetch
+ - save-data
+ - speculative loading
+ - HTML performance
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, prefetch, resource-hints, navigation, frontend]
+---
+
+import {useState} from 'react';
+
+export function prefetchValue(chance, sizeKb, mbps) {
+ const seconds = (sizeKb * 8) / (mbps * 1000);
+ const wastedKb = Math.round((1 - chance) * sizeKb);
+ let verdict = "Probably skip it.";
+ if (chance >= 0.5 && sizeKb <= 1000) verdict = "Usually a good bet.";
+ else if (chance >= 0.3 && sizeKb <= 300) verdict = "Maybe, if the connection is not metered.";
+ return {seconds: Math.round(seconds * 10) / 10, wastedKb: wastedKb, verdict: verdict};
+}
+
+export function NextPageLab() {
+ const [chance, setChance] = useState(60);
+ const [sizeKb, setSizeKb] = useState(300);
+ const [mbps, setMbps] = useState(5);
+ const r = prefetchValue(chance / 100, sizeKb, mbps);
+ return (
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - If they go: the next page can skip about {r.seconds} s of download for this file.
+ - If they do not go: about {r.wastedKb} KB per visitor is wasted, on average.
+ - Verdict: {r.verdict}
+
+
+ This is a simplified model, and the verdict is a rule of thumb, not a law. It assumes the prefetch finishes before the click. Use your own analytics to estimate the real chance.
+
+
+
+ {!checked ? (
+
+ ) : (
+
+ Score: {score} of {plannerLinks.length}.{" "}
+
+
+ )}
+
+
+## The Big Idea
+
+A prefetch is a `link` element that names a file or page the visitor may need next.
+
+
+
+
+```html title="menu-page.html"
+
+
+ Menu | The Bread Bin
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the lab, drag the sliders. Prefetch is a bet: it pays off when many visitors go to the next page and the file is small, and it wastes data when few go, or the file is large.
+
+## What Prefetch Does
+
+1. **It fetches at low priority.** The browser waits until it is not busy with files the current page needs.
+2. **It stores the result.** The file goes into the browser's cache, to be used if the visitor asks for it later.
+3. **It keeps going after the visitor leaves.** Unlike most downloads, a prefetch can carry on while the next page is loading, which is the whole point.
+4. **It does not run or show anything.** A prefetched script does not run, and a prefetched page does not appear. It is simply ready, if needed.
+5. **It is a hint.** The browser can skip it, for instance on a slow connection or with data saving on, and support differs between browsers, so check [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/prefetch) before relying on it.
+
+## Prefetch vs Preload
+
+They look alike, but they answer different questions.
+
+| Question | Preload | Prefetch |
+| :-- | :-- | :-- |
+| Which page is it for? | This page, now | The next page, maybe |
+| Priority | High | Low |
+| Is `as` needed? | Yes | Optional, but helpful |
+| What if it is wasted? | Competes with this page | Wastes data and bandwidth |
+| Typical use | Fonts, hero images, late-found files | The next page, or the files it needs |
+
+A simple rule: if the **current** page needs it, use preload (or better, put it in the HTML). If only the **next** page might need it, use prefetch. Using prefetch for something the current page needs is a mistake, because the low priority means it arrives late.
+
+## What Gets Prefetched for a Page
+
+If you prefetch a page address, the browser usually fetches just that one HTML file. The files that page uses (its stylesheets, scripts, and images) are not automatically included. So for a smoother jump, you may prefetch the key files as well:
+
+```html
+
+
+
+```
+
+How much of this helps depends on your caching headers. A file the server marks as cacheable will be kept and reused. Behaviour for files that are not cacheable differs between browsers, so test in the ones your visitors use.
+
+## Choosing What to Prefetch
+
+Prefetch only when all of these are true:
+
+- **It is likely.** A good rule of thumb is that around half of visitors, or more, go there next.
+- **It is small.** A big page or file is a big bet.
+- **It is public and safe.** A plain GET request that changes nothing and holds nothing private.
+- **It is useful in the cache.** The page or file can actually be reused when the visitor arrives.
+
+Try your judgement on a bakery site. Tick the links you would prefetch, then check.
+
+
+<>
+
+
+
+
+## Prefetching on Hover or When Idle
+
+You do not have to prefetch everything on page load. A common, careful approach is to prefetch when the visitor shows interest, for example when they hover a link. This keeps the bet small, because they are clearly considering it.
+
+```js
+const done = new Set();
+
+function prefetch(url) {
+ if (done.has(url)) return;
+ const c = navigator.connection;
+ if (c && (c.saveData || /2g/.test(c.effectiveType))) return;
+ done.add(url);
+ const link = document.createElement("link");
+ link.rel = "prefetch";
+ link.href = url;
+ document.head.appendChild(link);
+}
+
+document.querySelectorAll("a[data-prefetch]").forEach(function (a) {
+ if (a.origin !== location.origin) return;
+ a.addEventListener("mouseenter", function () { prefetch(a.href); }, { once: true });
+});
+```
+
+A few notes about this code:
+
+- It only prefetches links you mark with `data-prefetch`, so you choose which ones.
+- It skips visitors who ask to save data, or are on very slow connections. `navigator.connection` is not available in every browser, which is why the code checks that it exists first.
+- It stays on your own site, and never repeats a link.
+- On touch screens there is no hover, so you might prefetch when a link scrolls into view instead, or on a touch start.
+
+:::info
+Newer tools exist for this job. **Speculation rules** let you describe pages to prefetch, or even pre-render, in a block of JSON, and some frameworks and tools prefetch links for you. Support varies, so check current browser support before you depend on them.
+:::
+
+## Prefetch and Your Numbers
+
+Prefetch requests are real requests. They show up in your server logs, and some analytics setups may count a prefetched page as a visit. Many browsers add a header to mark them (Chromium uses `Sec-Purpose: prefetch`, for example), which your server can use to tell prefetches from real visits. Check the current documentation for the browsers you care about.
+
+## Checking That It Worked
+
+1. Open DevTools, then **Network**, and load the first page. Look for your prefetched file. It should appear with a low priority.
+2. Click through to the next page. The prefetched file should now be loaded **from cache** (look for "disk cache" or "prefetch cache" in the Size column), not downloaded again.
+3. Compare the time to load the next page with and without the prefetch.
+4. Check that nothing was prefetched that the visitor never saw or could not use.
+5. Test with the Network panel throttled, and with data saving on, to see how the code behaves.
+
+## Best Practices
+
+1. **Prefetch the likely, not the possible.**
+2. **Keep it small,** or prefetch only the key files.
+3. **Use hover or idle triggers** to keep the bet small.
+4. **Respect data saving** and slow connections.
+5. **Prefetch only public, safe pages.**
+6. **Set good caching headers,** so the prefetched file is reusable.
+7. **Use analytics to find your real next steps,** not guesses.
+8. **Do not prefetch what the current page needs.** Use preload, or put it in the HTML.
+
+## Quick Checklist
+
+- [ ] Each prefetch is for a likely next step
+- [ ] Each file is small, or the page is light
+- [ ] No action, logout, delete, or private URL is prefetched
+- [ ] Data saving and slow connections are respected
+- [ ] The prefetched file is cacheable
+- [ ] The Network panel shows it used from cache on the next page
+- [ ] Analytics and server logs account for prefetch requests
+
+## Security and Privacy Notes
+
+- **A prefetch is a real request.** The server sees it, cookies are sent, and anything the URL does will happen. Never prefetch a link that changes something (logging out, deleting, adding to a basket, confirming). Good design makes such actions a POST request from a button, not a link, but do not rely on that alone.
+- **Never prefetch private or one-time URLs,** such as pages with tokens in the address, password reset links, or order confirmations.
+- **Do not prefetch personalised pages into shared caches.** Check your cache headers so private pages are never stored where other people can see them.
+- **Prefetch can share visitor details with third parties.** Fetching a file from another host tells that host about the visitor. If you need consent before contacting certain services, do not prefetch from them until it is given. Browsers also increasingly keep separate caches per site, so a prefetch from another host may not be reused the way you expect.
+- **Respect the visitor's choice.** If they have asked to save data, a prefetch is a poor use of it.
+
+## Global Audience Notes
+
+- **Prefetch costs real money for some visitors.** On pay-as-you-go plans, a guess that misses is not free. Respect data-saving settings, and keep prefetches small.
+- **Slow connections gain the most when the guess is right,** and lose the most when it is wrong. Be especially conservative for them.
+- **Visitors far from your server feel latency more,** so a prefetch that lands in the cache can help, if the file is small and likely.
+- **Test on slow networks and modest phones,** since prefetch competes for the same limited resources.
+
+## Common Mistakes to Avoid
+
+1. **Prefetching everything.**
+2. **Prefetching large files or pages.**
+3. **Prefetching links that do something,** like logout or delete.
+4. **Prefetching private or tokenised URLs.**
+5. **Using prefetch for files the current page needs.**
+6. **Ignoring data saving.**
+7. **Prefetching files that are not cacheable,** so the work is lost.
+8. **Not noticing the extra requests in your analytics.**
+9. **Prefetching third-party files without thinking about privacy.**
+10. **Never checking the next page** to see if the cache was used.
+
+## Practice Time
+
+1. In the Next Page Lab, find a case where prefetch is a clear yes, and one where it is a clear no.
+2. In the link planner, which choice surprised you?
+3. Think about a site you use. Which page is the most likely next step from its home page?
+4. Add a prefetch for that page on a test site, and check the Network panel.
+5. Click through, and see if the file came from cache.
+6. Try the hover script on a few links.
+7. Turn on data saving in your browser, if it has the option, and see if the script holds back.
+8. Bonus: look at your analytics to find the three most common two-page journeys.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What does prefetch do?
+
+It downloads a file or page at low priority and stores it in the cache, so it is ready if the visitor needs it later, usually on the next page.
+
+
+
+
+2. How is prefetch different from preload?
+
+Preload is for files the current page needs, at high priority. Prefetch is for files the next page may need, at low priority.
+
+
+
+
+3. When is prefetch worth it?
+
+When the next step is likely (about half of visitors or more is a useful rule of thumb), the file is small, it is public and safe, and it can be reused from the cache.
+
+
+
+
+4. What should never be prefetched?
+
+Links that perform actions (logout, delete, confirm), private or one-time URLs, and personalised pages that must not be cached.
+
+
+
+
+5. How can you keep prefetching cheap?
+
+Prefetch on hover or when idle, keep files small, and skip visitors who have data saving on or slow connections.
+
+
+
+
+6. How do you know prefetch worked?
+
+In the Network panel, the file loads at low priority on the first page, and on the next page it comes from cache instead of being downloaded again.
+
+
+
+## Key Takeaways
+
+- **Prefetch prepares the next page,** quietly, at low priority.
+- **It is a bet.** Make it when the odds are good and the cost is small.
+- **Do not use it for what this page needs.** That is preload's job.
+- **Never prefetch actions or private URLs.**
+- **Respect data saving and slow connections.**
+- **Make files cacheable,** and check the next page used the cache.
+- **Remember your analytics:** prefetches are real requests.
+
+Next up: [DNS Prefetch](./dns-prefetch), a very cheap hint that looks up a server's address before you need it.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/preload.mdx b/tutorials/html/15-performance/preload.mdx
new file mode 100644
index 000000000..3a51f5b74
--- /dev/null
+++ b/tutorials/html/15-performance/preload.mdx
@@ -0,0 +1,520 @@
+---
+id: html-perf-preload
+title: "Preload in HTML"
+sidebar_label: "Preload"
+sidebar_position: 4
+slug: /html/performance/preload
+description: "Learn link rel=preload: fetch the files your page needs but finds late, such as fonts and CSS background images. Includes a discovery timeline and a checker for as and crossorigin mismatches."
+keywords:
+ - link rel preload
+ - preload fonts
+ - preload hero image
+ - as attribute
+ - crossorigin preload
+ - imagesrcset preload
+ - preload CSS
+ - late discovery
+ - HTML performance
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, preload, resource-hints, fonts, images, frontend]
+---
+
+import {useState} from 'react';
+
+export function simulateDiscovery(o) {
+ const cssDone = 600;
+ const jsRun = 800;
+ const early = 250;
+ const kinds = {
+ font: {label: "A font named inside the CSS", found: cssDone, duration: 300, needsPage: cssDone},
+ bg: {label: "A hero image set as a CSS background", found: cssDone, duration: 500, needsPage: cssDone},
+ html: {label: "A hero image in an img tag", found: early, duration: 500, needsPage: 0},
+ js: {label: "An image chosen by JavaScript", found: jsRun, duration: 500, needsPage: jsRun}
+ };
+ const k = kinds[o.kind];
+ const run = function (preload) {
+ const start = preload ? early : k.found;
+ const end = start + k.duration;
+ return {start: start, end: end, ready: Math.max(end, k.needsPage)};
+ };
+ const without = run(false);
+ const withP = run(true);
+ return {label: k.label, without: without, withPreload: withP, saved: without.ready - withP.ready};
+}
+
+export function DiscoveryLab() {
+ const [kind, setKind] = useState("font");
+ const r = simulateDiscovery({kind: kind});
+ const scale = 1400;
+ const kinds = [
+ ["font", "Font in CSS"],
+ ["bg", "CSS background image"],
+ ["html", "Image in HTML"],
+ ["js", "Image set by JavaScript"]
+ ];
+ const bar = function (row, color) {
+ return (
+
+ );
+ };
+ return (
+
+
+
Without preload: starts at {r.without.start} ms, ready at {r.without.ready} ms
+ {bar(r.without, "#c0392b")}
+
With preload: starts at {r.withPreload.start} ms, ready at {r.withPreload.ready} ms
+ {bar(r.withPreload, "#1e8449")}
+
+ {r.saved > 0 ? "Preload makes this ready about " + r.saved + " ms sooner." : "Preload changes nothing here. The browser already finds this file early."}
+
+
+ This is a simplified model with fixed numbers (the CSS arrives at 600 ms, the script runs at 800 ms). Real pages vary, so measure your own.
+
+
+
+
+ {r.reused ? "Match: the browser can reuse the preloaded file." : "No match: the file may be downloaded twice."}
+
+
+ {r.reasons.map(function (x, i) { return - {x}
; })}
+
+
+ This shows the general rule. Browsers differ in small details, so confirm in DevTools that the file is requested only once.
+
+
+
+ Answered {done} of {decisionItems.length}. Correct: {correct}.
+
+ {decisionItems.map(function (item, i) {
+ const chosen = picked[i];
+ const answered = chosen !== undefined;
+ return (
+
+ );
+ })}
+ {done > 0 ?
: null}
+
+
+## The Big Idea
+
+A preload goes in the `head` and names a file the page will need soon. The browser fetches it at high priority and keeps it ready.
+
+
+
+
+```html title="index.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+
+
+```
+
+```css title="site.css"
+@font-face {
+ font-family: "Inter";
+ src: url("/fonts/inter.woff2") format("woff2");
+ font-display: swap;
+}
+
+.hero {
+ background-image: url("/img/hero.webp");
+}
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the lab, try each kind of file. Preload helps most when a file is found late, and does nothing when the browser would find it early anyway.
+
+## What Preload Does
+
+1. It starts the download early, at the high priority that the `as` value suggests.
+2. It stores the result, so when the page asks for the file the browser can use it straight away.
+3. It does **not** use the file. A preloaded script does not run, a preloaded stylesheet does not apply, and a preloaded image does not appear. The page still has to ask for the file in the normal way.
+
+This last point is important. A preload only makes the file arrive sooner. If nothing on the page uses it, you have wasted a download.
+
+## The `as` Attribute
+
+The `as` value tells the browser what kind of file it is fetching. It affects priority and request headers, and it lets the browser match the preload to the later request.
+
+| `as` value | Use it for | Notes |
+| :-- | :-- | :-- |
+| `font` | Web fonts | Always add `crossorigin`, and `type` such as `font/woff2` |
+| `image` | Images | Works for CSS backgrounds too |
+| `style` | Stylesheets | See the CSS section below |
+| `script` | JavaScript | The script is fetched, not run |
+| `fetch` | Data requested with `fetch()` | Often needs `crossorigin` |
+
+Leaving out `as` is a mistake: the browser may give the file the wrong priority, or fetch it again later.
+
+## The `crossorigin` Trap
+
+Fonts are always fetched in a mode that needs `crossorigin`, even when they live on your own site. If your preload lacks it, the browser treats the preloaded file as a different request, and downloads the font a second time. You pay twice, and the preload helped nobody.
+
+Try the checker. It starts with exactly this mistake:
+
+
+<>
+
+
+
+
+Check the box for `crossorigin` and see the result change. Then try changing the URL by one letter, or the `as` value, and watch the other reasons appear. The preload and the real request must agree on **URL, `as`, and `crossorigin`**.
+
+## Preloading Responsive Images
+
+If your main image uses `srcset` and `sizes`, a plain preload would fetch the wrong size on some screens. Use `imagesrcset` and `imagesizes` so the browser picks the same file the `img` will:
+
+```html
+
+```
+
+The `href` is a fallback for browsers that do not understand the other two attributes. Check [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload) for current support.
+
+You can also limit a preload to certain screens using `media`, for example to preload a different image only on wide screens:
+
+```html
+
+```
+
+## Preloading CSS
+
+Your main stylesheet is already a `link` in the head, so it needs no preload. But a stylesheet that the browser finds late, such as one imported from another CSS file, can benefit from one. If you are looking for a trick to load non-critical CSS without blocking, a well-known pattern is:
+
+```html
+
+
+```
+
+This loads the file early without blocking the first paint, then applies it. It needs JavaScript, which is why the `noscript` fallback is there, and the inline `onload` may conflict with a strict content security policy. Treat it as an advanced tool, and test it carefully.
+
+## Deciding What to Preload
+
+The test is simple: **will the browser find this file late, and is it important to the first screen?** If both are true, preload it. If not, leave it alone.
+
+
+<>
+
+
+
+
+:::tip
+Preload is a repair for late discovery, not a replacement for good HTML. If you can put the hero image in an `img` tag instead of a CSS background, the browser finds it early and you need no preload at all.
+:::
+
+## Preload in an HTTP Header
+
+If you cannot edit the HTML, the server can send the same instruction as a header:
+
+```http
+Link: ; rel=preload; as=font; type="font/woff2"; crossorigin
+```
+
+This is useful on platforms where headers are easier to change than templates. Use one place or the other for each file, so you do not repeat the hint.
+
+## Checking That It Worked
+
+1. Open DevTools, then **Network**, and reload.
+2. Find the file. It should appear **once**, not twice. Two entries usually mean a mismatch in `as`, `crossorigin`, or the URL.
+3. Check the **Waterfall**. The preloaded file should start near the top, before the CSS has finished.
+4. Check the **Console**. Chrome warns when a file was preloaded but not used soon after the page loaded, and when `crossorigin` does not match.
+5. Run Lighthouse or WebPageTest before and after. For an image, look at your Largest Contentful Paint (LCP).
+
+## Best Practices
+
+1. **Preload only what is both late-found and important.**
+2. **Keep the list very short.** A few preloads at most, for the files that really lead the first screen.
+3. **Always include `as`,** and `type` for fonts.
+4. **Match the real request:** the same URL, the same `as`, the same `crossorigin`.
+5. **Use `imagesrcset` and `imagesizes`** for responsive images.
+6. **Do not preload what the browser already finds early.**
+7. **Remove a preload when you remove the file it points to.**
+8. **Measure.** A preload that does not improve a number is just clutter.
+
+## Quick Checklist
+
+- [ ] Each preload is for a file the page uses on the first screen
+- [ ] The browser would not have found the file early on its own
+- [ ] `as` is present and correct
+- [ ] Font preloads have `crossorigin` and `type`
+- [ ] The URL matches the real request exactly
+- [ ] The file appears only once in the Network panel
+- [ ] There are no console warnings about unused preloads
+
+## Security and Privacy Notes
+
+- **Preload runs nothing, but it fetches early.** Treat the URLs like any other request: only point at files you trust.
+- **Use `integrity` for fixed files.** For a script or style that never changes, an `integrity` attribute on the preload lets the browser check it is the file you expect, as long as the real use includes the matching value.
+- **Preload only public resources.** A preload is requested whether or not the page ends up using it, so do not point it at private, personal, or one-time URLs.
+- **Third-party files share visitor details.** A preload from another host contacts that host straight away, which shares the visitor's network address and some request details with it. If you need consent before this, wait for it.
+- **Do not put secrets in URLs.** Hint URLs are visible in the page source and may be logged.
+
+## Global Audience Notes
+
+- **Every wasted preload costs data,** and in many places data is expensive. Keep preloads to the files that truly matter.
+- **Preloading a large font can slow down slow connections.** Subset fonts, especially large ones for Chinese, Japanese, and Korean, and preload only the weights you need on the first screen.
+- **Slow networks make late discovery hurt more,** so a good preload helps those visitors most.
+- **Test with a slow connection and a modest phone,** not only on your own machine.
+
+## Common Mistakes to Avoid
+
+1. **Leaving out `as`.**
+2. **Forgetting `crossorigin` on fonts.**
+3. **A URL that differs from the real request,** even by a query string.
+4. **Preloading a file that is never used.**
+5. **Preloading something the browser finds early anyway.**
+6. **Preloading many files,** so the important ones are no longer special.
+7. **Preloading the wrong size of a responsive image.**
+8. **Expecting a preloaded script to run.**
+9. **Forgetting to remove old preloads after a redesign.**
+10. **Never checking the Network panel.**
+
+## Practice Time
+
+1. In the Discovery Lab, which kind of file gains the most from a preload? Which gains nothing?
+2. In the checker, fix the font preload so the browser can reuse it.
+3. Change the real use to an `img` with `crossorigin`. What does the preload need now?
+4. Take the preload quiz. Which question surprised you?
+5. Find a page you built with a font or a CSS background image. Open the Network panel, and see when that file starts.
+6. Add a preload, reload, and see if it moved.
+7. Check the console for warnings.
+8. Bonus: preload a responsive image with `imagesrcset` and `imagesizes`, and make sure it is fetched only once.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What does preload do?
+
+It tells the browser to download a file early, at high priority, and keep it ready. It does not run or apply the file.
+
+
+
+
+2. Which files are worth preloading?
+
+Important files the browser finds late, such as fonts named in CSS, CSS background images, and files requested by scripts.
+
+
+
+
+3. Why is `as` required?
+
+It tells the browser what kind of file it is, so it can use the right priority and headers, and match the preload to the later request.
+
+
+
+
+4. Why do font preloads need `crossorigin`?
+
+Fonts are fetched in CORS mode, even from your own site. Without `crossorigin` the preload does not match the real request, and the font is downloaded twice.
+
+
+
+
+5. How do you preload a responsive image?
+
+Use `imagesrcset` and `imagesizes` on the `link` element, so the browser picks the same file the `img` will.
+
+
+
+
+6. How do you know a preload is not working?
+
+The file appears twice in the Network panel, or the console warns that it was preloaded but not used. Fix the URL, `as`, or `crossorigin`, or remove the preload.
+
+
+
+## Key Takeaways
+
+- **Preload fetches a file early,** so it is ready when the page asks for it.
+- **It helps most with files discovered late:** fonts in CSS, CSS backgrounds, and script-chosen images.
+- **It does not run or apply anything.**
+- **Always include `as`,** and `crossorigin` for fonts.
+- **The preload and the real request must match.**
+- **Keep it short and measure it.** An unused preload is waste.
+- **Where you can, put important files in the HTML,** so you do not need a preload at all.
+
+Next up: [Prefetch](./prefetch), where you will warm up files for the page the visitor will probably open next.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/resource-hints.mdx b/tutorials/html/15-performance/resource-hints.mdx
new file mode 100644
index 000000000..41ed42170
--- /dev/null
+++ b/tutorials/html/15-performance/resource-hints.mdx
@@ -0,0 +1,526 @@
+---
+id: html-perf-resource-hints
+title: "Resource Hints in HTML"
+sidebar_label: "Resource Hints"
+sidebar_position: 3
+slug: /html/performance/resource-hints
+description: "Learn what resource hints are and how to choose between dns-prefetch, preconnect, preload and prefetch. Includes a hint builder and a live checker for common mistakes."
+keywords:
+ - resource hints
+ - dns-prefetch
+ - preconnect
+ - preload
+ - prefetch
+ - link rel
+ - crossorigin
+ - modulepreload
+ - HTML performance
+ - learn HTML
+ - CodeHarborHub HTML
+tags: [html, web-development, beginner, performance, resource-hints, preload, preconnect, frontend]
+---
+
+import {useState} from 'react';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import BrowserOnly from '@docusaurus/BrowserOnly';
+import AdsComponent from '@site/src/components/AdsComponent';
+import BrowserWindow from '@site/src/components/BrowserWindow';
+
+export function escapeAttr(v) {
+ return String(v).replace(/&/g, "&").replace(/"/g, """).replace(//g, ">");
+}
+
+export function buildHint(o) {
+ const notes = [];
+ const href = o.href.trim();
+ const parts = ['rel="' + o.rel + '"'];
+ if (href === "") {
+ notes.push({level: "problem", text: "Enter a URL. A hint with no address does nothing."});
+ }
+ parts.push('href="' + escapeAttr(href) + '"');
+ let crossorigin = o.crossorigin;
+ if (o.rel === "preload" || o.rel === "prefetch") {
+ if (o.as === "") {
+ if (o.rel === "preload") {
+ notes.push({level: "problem", text: "A preload needs an as value, so the browser knows what kind of file it is."});
+ }
+ } else {
+ parts.push('as="' + o.as + '"');
+ }
+ if (o.as === "font") {
+ crossorigin = true;
+ notes.push({level: "tip", text: "Fonts are always fetched in anonymous CORS mode, so a font preload needs crossorigin, even from your own site. Without it the browser can download the font twice."});
+ }
+ }
+ if (o.rel === "preconnect" || o.rel === "dns-prefetch") {
+ try {
+ const u = new URL(href);
+ if (u.pathname !== "/" || u.search !== "") {
+ notes.push({level: "tip", text: "Only the origin matters here (for example " + u.origin + "). The path is ignored, so you can drop it."});
+ }
+ } catch (e) {
+ if (href !== "") notes.push({level: "problem", text: "Use a full origin such as https://cdn.example.com."});
+ }
+ }
+ if (o.rel === "preconnect" && !crossorigin) {
+ notes.push({level: "tip", text: "If the files from this host load in CORS mode (fonts, or fetch requests), add crossorigin. Otherwise the opened connection may not be reused."});
+ }
+ if (crossorigin) parts.push("crossorigin");
+ if (o.rel === "prefetch") {
+ notes.push({level: "tip", text: "Prefetch is for a file the visitor will probably need on the next page. It runs at low priority, and the browser may skip it."});
+ }
+ if (o.rel === "dns-prefetch") {
+ notes.push({level: "tip", text: "dns-prefetch only looks up the address. It is cheap, and a good fallback next to preconnect."});
+ }
+ return {tag: "", notes: notes};
+}
+
+export function HintBuilder() {
+ const [rel, setRel] = useState("preload");
+ const [href, setHref] = useState("/img/hero-1200.webp");
+ const [as, setAs] = useState("image");
+ const [crossorigin, setCrossorigin] = useState(false);
+ const r = buildHint({rel: rel, href: href, as: as, crossorigin: crossorigin});
+ const usesAs = rel === "preload" || rel === "prefetch";
+ return (
+
+
+
+
+
+
+
+ {usesAs ? (
+
+
+
+
+
+ ) : null}
+
+
+
+
{r.tag}
+
+ {r.notes.map(function (n, i) {
+ return (
+ -
+ {n.level === "problem" ? "Problem: " : "Tip: "}
+ {n.text}
+
+ );
+ })}
+
+
+
+
+
+
+
+
+
+ {problems === 0 ? "No problems found." : problems + " problem(s) found."}
+
+
+ {results.map(function (r, i) {
+ return (
+ -
+ {labels[r.level]}:
+ {r.text}
+
+ );
+ })}
+
+
+ This is a teaching checker. It looks at the markup only, so it cannot tell whether a hinted file is actually used. DevTools can.
+
+
+
+## The Big Idea
+
+All four hints are written with the same element, `link`, and the `rel` attribute chooses the job.
+
+
+
+
+```html title="index.html"
+
+
+ The Bread Bin
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+
+<>
+
+
+
+
+
+
+
+In the builder, switch between the four hints and notice what changes: `as` appears for preload and prefetch, and the notes change with the hint. In the checker, load the messy head and fix every problem it reports.
+
+## The Four Hints at a Glance
+
+The four hints sit on a ladder from cheapest and safest to most costly. The first two prepare a connection. The last two download a file.
+
+| Hint | What the browser does | Cost | Best for |
+| :-- | :-- | :-- | :-- |
+| `dns-prefetch` | Looks up the server's address | Very small | Third-party hosts you might use |
+| `preconnect` | Looks up the address, connects, and sets up security | Small, but a connection stays open | The few hosts you will use very soon |
+| `preload` | Downloads one file for this page, early, at high priority | Real bandwidth | A file the page needs but finds late |
+| `prefetch` | Downloads a file at low priority, for later | Real bandwidth, spent on a guess | Likely next pages or files |
+
+You will go deeper into each one in its own lesson: [Preload](./preload), [Prefetch](./prefetch), [DNS Prefetch](./dns-prefetch), and [Preconnect](./preconnect).
+
+## They Are Only Hints
+
+The word matters. A resource hint is a request, not a command. A browser may act on it, delay it, or ignore it, depending on the connection, the device, settings such as data saving, and how busy it already is. Support also differs between browsers, so always check [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel) for the hint you plan to use.
+
+Two things follow from this:
+
+1. **Your page must work without the hints.** A hint speeds things up. It should never be required for the page to work.
+2. **Test, do not assume.** A hint that helps on your fast laptop might do nothing, or even hurt, on a slow phone.
+
+## Which One Do I Need?
+
+Ask two questions: *is the file for this page or the next?* and *do I know exactly which file?*
+
+1. **I know the exact file, this page needs it, and the browser will find it late.** Use `preload`. Typical examples are a font named inside CSS, or a hero image set as a CSS background.
+2. **I know the server, but not the files.** Use `preconnect` if you will use the server almost straight away, or `dns-prefetch` if you might.
+3. **The visitor will probably go to a certain page next.** Use `prefetch` for that page or file.
+4. **The browser will find the file early anyway.** Use nothing. A normal image or stylesheet in your HTML is already found early.
+
+:::tip
+The best resource hint is often no hint at all. If you can move a file earlier in the HTML, or put an image in the HTML instead of in CSS, the browser finds it by itself, and you have one less thing to maintain.
+:::
+
+## Two Details That Trip People Up
+
+### The `as` attribute
+
+A preload must say what kind of file it is, using `as`. The browser uses this to give the file the right priority, and to send the right request headers. Without it, the browser may fetch the file twice or give it the wrong priority.
+
+```html
+
+
+
+```
+
+### The `crossorigin` attribute
+
+Fonts, and anything fetched in "CORS mode", need `crossorigin`, even when they come from your own site. If the hint and the real request do not match, the browser cannot reuse the preloaded file, and downloads it again.
+
+```html
+
+```
+
+The same idea applies to `preconnect`: if the files will be fetched in CORS mode, add `crossorigin` to the hint, so the open connection can be reused.
+
+## Hints in Other Places
+
+You can send the same hints from the server, as an HTTP header, which is useful when you cannot edit the HTML:
+
+```http
+Link: ; rel=preload; as=image
+```
+
+Two related ideas you may meet later:
+
+- **`modulepreload`** is a version of preload made for JavaScript modules (``).
+- **Speculation rules** are a newer way to prefetch or even pre-render a whole next page. Support is not universal, so check current browser support before you rely on it.
+
+## When Hints Hurt
+
+Hints are not free. Each one uses bandwidth, a connection, or the browser's attention.
+
+- **Preload too much** and files compete with each other, and with the files that matter. If everything is high priority, nothing is.
+- **Preconnect to many hosts** and you open connections that may sit unused. Browsers close idle connections after a short time, so a hint for something used much later can be wasted.
+- **Preload a file you do not use** and Chrome will warn in the console that the file was preloaded but not used soon after load. That is a sign to remove the hint.
+- **Prefetch on a slow or metered connection** can cost visitors data for pages they never open.
+
+:::warning
+Add hints one at a time, and measure after each change. Remove any hint that does not clearly help.
+:::
+
+## Checking That a Hint Worked
+
+1. Open DevTools, then the **Network** panel, and reload.
+2. Find your file, and look at the **Priority** and **Initiator** columns. A preloaded file should start early, with an initiator showing the preload.
+3. Check the **Waterfall**. A good preload makes the file start near the top, not after a stylesheet or script finishes.
+4. Watch the **Console** for warnings about unused preloads or mismatched `crossorigin`.
+5. Run Lighthouse or WebPageTest before and after, and compare your key numbers, such as Largest Contentful Paint (LCP).
+
+## Best Practices
+
+1. **Make the file easy to find first.** Hints are a fix for late discovery, not a replacement for good HTML.
+2. **Keep the list short.** A few well-chosen hints beat a long list.
+3. **Always add `as` to a preload,** and `crossorigin` where needed.
+4. **Match the hint to the real request,** with the same URL, the same `as`, and the same `crossorigin`.
+5. **Use `dns-prefetch` as a cheap fallback** next to `preconnect`, for older browsers.
+6. **Never rely on a hint** for the page to work.
+7. **Re-check after redesigns,** since a hint for a file you no longer use is pure waste.
+
+## Quick Checklist
+
+- [ ] Each hint points to something the page really uses (or will probably use next)
+- [ ] Every preload has an `as` value
+- [ ] Font preloads and font-host preconnects have `crossorigin`
+- [ ] No hint is repeated
+- [ ] Only a few preconnects, for the hosts that matter most
+- [ ] No private or one-time URLs are prefetched
+- [ ] DevTools shows the hint helped, and the console shows no warnings
+
+## Security and Privacy Notes
+
+- **Hints contact other servers early.** `preconnect` and `dns-prefetch` make the visitor's browser contact a third party before the visitor does anything, which shares their network address and some connection details. If you need consent before contacting certain services (analytics or advertising, for example), do not hint those hosts until consent is given. This is not legal advice, so check the rules that apply to you.
+- **Prefetch only public pages.** A prefetched address is requested whether or not the visitor ever goes there. Never prefetch a logout link, an action link, or any URL that changes something or is private.
+- **Use `integrity` when it fits.** For a preloaded script or style that does not change, the `integrity` attribute lets the browser check the file is the one you expect.
+- **Do not leak secrets in URLs.** Hint URLs are visible in the page source and can end up in server logs.
+
+## Global Audience Notes
+
+- **Slow networks benefit most, and suffer most from waste.** A needless preload costs a visitor on a limited plan real data.
+- **Distant servers add delay to every new connection,** which makes `preconnect` more valuable for visitors far from your host.
+- **Some third-party hosts are slow or blocked in some countries.** A preconnect to a host that never answers wastes time, so make sure the page works without it.
+- **Test from other places and on slow connections,** because a hint that helps in one region may not help in another.
+
+## Common Mistakes to Avoid
+
+1. **Preloading without `as`.**
+2. **Forgetting `crossorigin` on fonts.**
+3. **Preloading a file the page does not use.**
+4. **Hinting at files the browser would find at once.**
+5. **Preloading everything,** so nothing stands out.
+6. **Preconnecting to a dozen hosts.**
+7. **Writing the same hint twice.**
+8. **Prefetching private or action URLs.**
+9. **Putting a path in a preconnect** and thinking it matters.
+10. **Never measuring** whether the hint helped.
+
+## Practice Time
+
+1. In the builder, create a preload for a font. What does it add on its own?
+2. Create a preconnect with a long URL. What does the note tell you?
+3. Load the messy head into the checker and fix every problem it reports.
+4. Open DevTools on a page you built. Is any file discovered late?
+5. Add a preload for that file, reload, and compare the waterfall.
+6. Add a preload for a file you do not use, and look in the console. What does Chrome say?
+7. Find a page where `prefetch` would make sense, and write down why.
+8. Bonus: run Lighthouse before and after your change, and compare LCP.
+
+## Quick Recap
+
+Click a question to check your answer.
+
+
+1. What is a resource hint?
+
+A `link` element that tells the browser about a file or server before it would normally find out. It is a request, and the browser may ignore it.
+
+
+
+
+2. What is the difference between preconnect and dns-prefetch?
+
+`dns-prefetch` only looks up the server's address. `preconnect` also opens the connection and sets up security, so it saves more time but costs more.
+
+
+
+
+3. What is the difference between preload and prefetch?
+
+`preload` fetches a file this page needs, early, at high priority. `prefetch` fetches a file the next page may need, quietly, at low priority.
+
+
+
+
+4. Why does a preload need `as`?
+
+It tells the browser what kind of file it is, so it can set the right priority and request headers. Without it the file may be fetched twice or given the wrong priority.
+
+
+
+
+5. When do you need `crossorigin`?
+
+For fonts (always, even from your own site) and for any file fetched in CORS mode. The hint must match the real request, or the preloaded file cannot be reused.
+
+
+
+
+6. How can hints make a page slower?
+
+Too many preloads compete with important files, unused connections and downloads waste bandwidth, and prefetching on a slow connection costs data for pages nobody opens.
+
+
+
+## Key Takeaways
+
+- **Resource hints tell the browser what is coming,** so it can prepare earlier.
+- **They are hints, not commands,** and your page must work without them.
+- **`dns-prefetch` and `preconnect` prepare connections.** `preload` and `prefetch` download files.
+- **Preload is for this page, prefetch is for the next.**
+- **Always add `as` to a preload,** and `crossorigin` for fonts.
+- **Fewer, better hints win.** Measure each one, and remove what does not help.
+- **Mind privacy:** early connections reveal visitors to third parties, and prefetch must never touch private URLs.
+
+Next up: [Preload](./preload), where you will fetch the most important file on your page as early as possible.
\ No newline at end of file
diff --git a/tutorials/html/15-performance/responsive-images-performance.mdx b/tutorials/html/15-performance/responsive-images-performance.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/15-performance/script-loading.mdx b/tutorials/html/15-performance/script-loading.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/tutorials/html/index.mdx b/tutorials/html/index.mdx
index e21f3e0a7..7053044b2 100644
--- a/tutorials/html/index.mdx
+++ b/tutorials/html/index.mdx
@@ -24,14 +24,6 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import AdsComponent from '@site/src/components/AdsComponent';
-
-
**Learn HTML from the ground up and build real web pages for the modern web.**
HTML (HyperText Markup Language) is the standard markup language used to structure content on the web. Whether you want to become a frontend developer, full-stack developer, software engineer, designer who codes, or simply understand how websites work, HTML is one of the most important technologies to learn.