HTML响应式模板加载慢主因非模板体积，而是CSS/JS阻塞渲染、图片未压缩、字体请求失败或第三方资源拖垮首屏；须用Network面板定位前3个关键资源耗时是否超800ms。
HTML响应式模板加载慢，90%不是因为“模板本身大”，而是它自带的 CSS/JS 阻塞渲染、图片未压缩、字体请求失败或第三方资源拖垮了首屏。直接开 DevTools 的 Network 面板看 waterfall，比猜快得多。
为什么加了 loading="lazy" 还是卡在首屏？
原生懒加载只对 <img> 和 <iframe> 生效，且默认触发距离视口约 1250px——首屏 Hero 图、轮播第一张、关键按钮图标如果加了 loading="lazy"，浏览器会直接跳过，导致空白或回退加载，反而延长首屏时间。
- 首屏所有
<img>必须去掉loading="lazy"，显式写width和height（防 CLS） -
<picture>或<source>中的srcset不受loading控制，需单独检查是否包含高分辨率 fallback - Safari 15.4+ 才支持
loading="lazy"对<iframe>的解析；旧版安卓 WebView 可能完全忽略，得降级用data-src+IntersectionObserver - 别同时写
src和loading="lazy"再额外用 JS 监听——浏览器可能先加载src，造成重复请求
<link rel="stylesheet"> 放在 <head> 就安全？
不安全。外部 CSS 默认是 render-blocking 资源：哪怕它只用在页脚，只要在 <head> 里，整个页面就卡在白屏状态，直到下载并解析完成。
- 只提取首屏必需样式（如
body、.hero、.nav、@font-face），内联进<style>，体积控制在 gzip 后 ≤8KB（原始约 14KB） - 禁止在
<style>中用@import——它会触发新请求并串行阻塞 - 其余 CSS 用异步加载：
<link rel="stylesheet" href="app.css" media="print" onload="this.media='all'"> - 所有
<link rel="stylesheet">必须放在内联<style>之后，否则仍可能被后续资源拖慢
响应式模板里图片为啥一打开就卡死？
不是“响应式”本身的问题，而是模板常带的多张未压缩高清图（如 wallpaper.jpg、SiofokViztorony.jpg）在后台持续占用 GPU 显存和解码带宽，切出浏览器窗口后极易触发渲染线程挂起，表现为“假死”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- 目标单图体积：移动端 ≤300 KB，桌面端 ≤600 KB，质量保持 65%–75%
- 用
npx sharp或Squoosh.app转 WebP/AVIF，同时缩放到最大显示宽度（如 1200px） - CSS 背景图（如
background: url(wallpaper.jpg) fixed）是性能黑洞，必须替换为<picture>+srcset+media查询 - 禁用
background-attachment: fixed—— 它强制维持合成层，低端显卡极易爆内存
file:// 协议下测模板等于白测
双击打开 HTML 文件走的是 file:// 协议，浏览器禁用 gzip/Brotli、跳过 DNS 预解析、不支持 HTTP/2、无法缓存跨域资源，甚至 fetch('./data.json') 都可能被静默拒绝。所有服务端优化全失效，路径错一个、404 一次、base64 图片塞一串，就立刻暴露。
- 临时起本地服务器：Python 用户运行
python3 -m http.server，Node 用户用serve或http-server - 检查所有
src和href路径是否真实存在，特别注意./js/app.js和js/app.js的差异 - 禁用所有
data:image/内联图片——50KB base64 图片会让首屏延迟 100ms+ -
document.write()在file://下尤其敏感，执行即清空文档流，绝对禁用
真正卡住的从来不是 HTML 文件本身，而是它触发的连锁反应：一个未处理的字体请求、一张没压缩的背景图、一个硬编码的第三方脚本、或者只是把 <link> 放错了位置。优化必须从 Network 面板的 waterfall 时间线出发，逐个确认前 3 个资源（通常是 main.css、vendor.js、fonts.gstatic.com）是否耗时 >800ms——其他都是干扰项。
