外贸站页面所占用的空间大部分被图片占据了大约六到七成的带宽，而代码就是剩下的那部分里面最容易被忽略不计的一个“隐形负担”。把这两者都压缩一下，LCP（最大内容绘制）也就从四秒左右缩短到了两秒左右，并不是什么高深莫测的道理。
图片优化的第一步就是改变文件格式，在同一张产品的图片中，使用WebP格式可以达到75~82之间的质量水平，并且和JPG相比几乎没有区别的情况下把文件大小减少了六成左右；而AVIF格式则更进一步缩小了文件体积，但是它的编码过程需要更多的CPU资源，对于老旧设备的支持也存在一定的困难。实际操作的时候不需要只依赖一种格式，《<picture>》标签可以把AVIF放在前面、WebP居中、JPG放到后面去适应不同的浏览器选择。另外尺寸问题比格式更容易被跳过：一张四千像素宽的原始图片被压缩成三百像素宽度的展示区域时，即使转换成其他格式也无济于事，在上传之前最好裁剪到实际显示宽度的两倍以内再进行处理。
懒加载的一个高频翻车点就是，在首屏LCP图片上加上了loading="lazy"属性。该图为用户第一眼就能看到的主要视觉元素之一，因此对其进行延迟加载会直接增加白屏的时间长度。首屏重要的图片应该使用fetchpriority="high"来加载，并且只在首屏之外进行懒加载。
代码侧的压缩主要不是在服务器端进行，而是在构建的时候就把事情做好。Vite或者Webpack等构建工具可以借助插件提前生成.gz、.br文件，在Nginx中开启gzip_static和brotli_static来直接输出预压缩后的版本，从而避免了每次请求都要消耗CPU的情况发生。Brotli对于文本资源来说一般要比Gzip节省15%-20%的空间，但是前提是CDN或者源站支持这种格式。另外一种比较隐蔽的问题就是“带了但是没用”，即页面构建器、旧版插件以及废弃的UI组件所留下的CSS和JS代码虽然没有报错，但却会增加首屏请求的数据量。PurgeCSS或者构建工具中的Tree Shaking可以把不需要的模块去掉，这要比事后压缩更加有效。
2026年Core Web Vitals的标准也不会改变：LCP两秒半之内、INP两百毫秒之内、CLS零点一之内。做完优化之后，在本地运行Lighthouse得到的绿色分数和PageSpeed Insights中真实用户的表现数据不同，后者才是搜索引擎真正使用的指标。