很多人做站点运营，习惯盯着栏目、内鏈、收錄這些“内容层”的事，却很少回头看一個更基础的問题：一個頁面打開时，到底下载了多少東西。頁面自重過大、請求數過多，用戶會先走，抓取端也會更谨慎地分配時間。它不直接决定排名，但它會實實在在影响体驗和資料表現。
先量一遍：別凭感觉判断頁面轻重
優化要建立在資料上。打開浏览器開發者工具的 Network 面板，刷新一次目标頁面，重点看三個數字：總传輸体积、請求總數、首屏關键内容出現的時間。
- 總传輸体积：注意区分“资源大小”和“传輸大小”，後者才是真實網絡開销。
- 請求總數：JS、CSS、字体、图标、統計脚本都算，第三方脚本尤其容易被忽略。
- 首屏時間：用戶能讀到正文的最早时刻，比整頁加载完成更有參考價值。
建议固定用同一個頁面、同一網絡條件、同一设备類型测两三次，把结果记下来，作為後續對比的基线。没有基线，改動就無從判断好坏。
图片往往是第一大戶
在大多數内容型站点里，图片能占到頁面体积的一半以上。常见問题不是“图太多”，而是“图太大”。
几個高频毛病
- 直接上传相机原图，單張几 MB，展示区域却只有几百像素宽。
- 用 PNG 存照片，体积比同等画质的 JPEG 大好几倍。
- 列表頁每張缩略图都加载原图，一屏就拉動十几 MB。
- 懒加载寫错位置，把首屏大图也一起延迟，反而拖慢视觉呈現。
處理思路
按實际展示尺寸導出图片，長邊一般不超過容器宽度的两倍；照片類優先用 JPEG 或 WebP，图标线條類再考虑 SVG；對列表頁缩略图單獨生成小尺寸版本，不要复用一個原图地址；懒加载只用于首屏之外的图片，首屏主图應当正常優先加载。
脚本和样式：该省的省，该留的留
JS 和 CSS 的問题常常不是体积，而是數量和加载时机。
- 統計、客服、广告、A/B 測試等第三方脚本，逐個確認是否還在用，没用的直接摘掉。
- 非首屏必需的脚本，考虑放到頁面底部或按需加载，不要全部堆在头部阻塞渲染。
- 样式文件按頁面類型拆分，避免每頁都加载一個全站通用的大文件。
- 在 HTTP/2 环境下，不必强行把几十個小文件合並成巨型文件，两者要權衡。
改完记得回到 Network 面板复测，確認請求數真的降下来了，而不是從一個文件拆成了十個。
服務器與缓存：让重复訪問更轻
前端减负之後，服務端還有一层空間。
- 開啟文本压缩（gzip 或 brotli），HTML、CSS、JS、JSON 都能明顯瘦身。
- 给静態资源設定合理的缓存头，带版本号的文件可以设成長期缓存。
- 静態资源交给 CDN，就近响應，减少回源压力。
- 定期检查服務器响應時間，慢的後端會抵消前端所有優化。
一份可以直接照着做的自查清單
- 随机抽三個代表性頁面：首頁、栏目頁、内容頁。
- 分別记錄传輸体积、請求數、首屏時間，形成基线。
- 按体积排序，找出排名前三的资源，逐個判断能否压缩或移除。
- 检查是否有已下线的第三方脚本仍在加载。
- 確認首屏图片未被错誤地懒加载。
- 確認压缩與缓存头已生效，用响應头驗證而不是凭印象。
- 一周後复测同一批頁面，對比變化。
頁面性能是基础体驗的一部分，不是可以承诺的排名手段。把它做好，用戶更愿意留下，抓取时也更少浪費在等待上；但内容本身是否有用，仍然是另一件事。
最後提醒一句：不要為了追求分數而牺牲可讀性，比如把正文拆成一堆按钮点開的碎片，或者為了减少請求而把關键内容藏進脚本。優化的目标是让人更快看到内容，而不是让指标更好看。