食谱展示页应以语义化html为核心，用包裹每道菜，配料用、步骤用，分类用/，图片加loading="lazy"。
食谱展示页不是堆图片加文字就行，关键得让访客一眼看清「怎么做」，且能快速筛选、跳转、复用。静态页面也能做到高可用，重点在结构语义化、交互轻量、响应及时。
用 <article></article> 包裹每道菜，别用 <div> 硬套
<p>很多学生作业直接用一堆 <code><div class="dish"> 套内容，导致语义丢失、SEO 弱、屏幕阅读器难识别。浏览器和搜索引擎靠 HTML 标签理解内容层级。
<ul>
<li>
<code><article></article> 是语义化容器，天然表示独立、可分发的内容单元（一道菜就是一个独立实体）
<h2></h2>（菜名）、<ul></ul> 或 <ol></ol>（步骤/配料）、<figure></figure>（主图）<div id="list"> 里再 JS 渲染——静态页就该靠 HTML 原生结构承载信息
<h3>配料表和步骤必须用语义化列表，<code><ul></ul> 和 <ol></ol> 别混用
「配料」是无序集合，「步骤」是强顺序流程，HTML 的 <ul></ul> 和 <ol></ol> 不只是换序号样式，还影响可访问性和爬虫解析逻辑。
- 配料用
<ul></ul>：米、油、盐、葱花 —— 没先后，可任意调整顺序 - 步骤用
<ol></ol>：1. 热锅；2. 倒油；3. 下葱花 —— 缺一不可，顺序错就失败 - 别为了“好看”全用
<ul></ul>+ CSS 伪造数字序号，会破坏键盘 Tab 导航流和语音朗读逻辑
移动端折叠分类菜单时，details/summary 比 JS 更轻量可靠
常见做法是写一堆 <div class="category"> + jQuery toggle，但纯静态页没必要引入 JS 依赖，尤其当只做展开/收起时。
<ul>
<li>用原生 <code><details></details> + <summary></summary>：默认收起，点击展开，支持键盘空格/回车触发，无需 JS
<details><summary>川菜</summary><article><h2>麻婆豆腐</h2>…</article><article><h2>鱼香肉丝</h2>…</article></details>
图片加载慢？优先用 loading="lazy" + 合理尺寸，别急着上 WebP
学生作业常把 3000×2000 的原图直接丢进 <img>，导致首屏卡顿。优化不等于立刻切格式，先做最有效的事。
- 给所有非首屏图片加
loading="lazy"属性，浏览器原生懒加载，零 JS 成本 - 用 CSS 宽高比容器（如
aspect-ratio: 4/3）+object-fit: cover控制显示，避免拉伸变形 - WebP 虽好，但若用 Photoshop 批量导出时没关“元数据”，文件反而更大；不如先用
squoosh.app在线压一遍再放进去
真正卡住食谱页体验的，往往不是缺炫酷动画，而是结构松散、列表语义错乱、图片堵死主线程。把 <article></article>、<ol></ol>、loading="lazy" 这三样用对，80% 的性能和可访问问题就解了。
