大屏背景卡死？3个坑解决性能优化难题
前端做数据大屏，最怕什么？不是需求变，是屏幕一开就卡，刷新一下鼠标都动不了。更让人头秃的是，控制台红屏一片，StackTrace 长得像天书，看着报错一堆看不懂，心里慌得一批。很多兄弟第一反应是显卡不行，或者浏览器太老，其实十有八九，是你在大屏背景的处理上埋了雷。大屏背景看似只是几张图，但涉及渲染层合成、内存占用和重排重绘，稍有不慎，整个页面的性能优化就全完了。
今天咱们不整虚的，直接扒开大屏背景这三个最坑爹的问题。从现象到根因，从错误代码到正确写法，一步步带你避开这些坑。记住，大屏不是小页面，任何微小的性能损耗，在高分辨率下都会被放大十倍。
坑一：背景图无限重绘，CPU 飙升
现象：页面打开后，风扇狂转，温度飙升。打开任务管理器一看，Chromium 进程 CPU 占用率常年维持在 80%-100%。背景图明明没动，为什么一直在算？
根本原因：
很多兄弟喜欢用 background-image 加 background-size: cover 来铺满全屏。这本身没错，但问题出在“动效”上。如果你给背景图加了 transform: scale() 或者 animation，哪怕只是微小的缩放，浏览器就会判定该元素发生“重排”（Reflow）甚至“重绘”（Repaint）。
更隐蔽的坑是：背景图是 JPG 格式，且尺寸巨大（比如 4K 分辨率的图）。浏览器每帧都要解码这张图，然后进行光栅化（Rasterization）。如果背景层和其他内容层没有分离，每次页面有任何微小变化（比如数字跳动），浏览器都可能重新合成背景层。Stack Overflow 上有大量关于“Why is my CSS animation janky”的讨论，核心结论一致：不要在主线程做昂贵的位图操作。
错误写法 vs 正确写法
错误：直接用 JPG 大图做背景，并添加 CSS 动画。
/* 错误：JPG 大图 + CSS 动画，触发重绘 */
.dashboard-bg {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-4k.jpg'); /* 巨大的 JPG 文件 */
background-size: cover;
background-position: center;
/* 致命伤：这个动画会不断触发重绘 */
animation: pulse 4s infinite ease-in-out;
}
@keyframes pulse {
0% { transform: scale(1); }
50% { transform: scale(1.05); }
100% { transform: scale(1); }
}
正确：使用 WebP/AVIF 格式，且将动画隔离在独立合成层，或者使用 Canvas/WebGL 替代 CSS 动画。这里我们采用更稳妥的方案：静态背景 + 独立动效层。
/* 正确：静态背景，不动 */
.dashboard-bg {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-4k.webp'); /* 使用 WebP，体积更小，解码更快 */
background-size: cover;
background-position: center;
/* 关键：提升为独立合成层，避免与其他元素重排 */
will-change: transform;
z-index: -1;
}
/* 如果非要动效，加一个遮罩层或子元素做动画，而不是动背景图本身 */
.dashboard-bg-overlay {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background: radial-gradient(circle, rgba(255,255,255,0.1) 0%, rgba(0,0,0,0) 70%);
animation: overlayPulse 4s infinite ease-in-out;
pointer-events: none; /* 不阻挡交互 */
}
@keyframes overlayPulse {
0% { opacity: 0.8; }
50% { opacity: 1; }
100% { opacity: 0.8; }
}
规避建议：
格式转换：永远不要用 JPG 做大屏背景。转成 WebP 或 AVIF，体积能减 50% 以上，解码速度更快。
动静分离：背景图尽量保持静态。如果需要呼吸灯效果，加一个半透明的 overlay 层做 opacity 动画，opacity 动画不会触发重排，只触发合成（Composite），性能极佳。
will-change：给背景元素加上 will-change: transform，提前告诉浏览器“这货要动”，让它尽早创建 GPU 纹理。
坑二：Canvas 高分屏适配导致内存爆炸
现象：在 Retina 屏或 4K 显示器上，页面直接白屏，或者浏览器提示“内存不足，已终止脚本”。小屏幕正常，一上大屏就崩。
根本原因：
很多团队喜欢用 Canvas 画科技感线条、粒子背景。代码里写 canvas.width = window.innerWidth。
在普通屏（DPR=1）下，1920x1080 的 Canvas，像素数是 200 多万。
但在 4K 屏（DPR=2 或 3）下，为了清晰，你通常会把 Canvas 物理尺寸放大。如果 DPR=2，实际像素就是 3840x2160，再乘以 DPR 的平方？不，是乘以 DPR。但如果你处理不当，比如手动乘以了 DPR 两次，或者在高分屏上开了大量粒子，每个粒子都要绘制，内存占用呈指数级上升。
Canvas 是位图，它的内存占用 = 宽 × 高 × 4（RGBA）。一个 4K 的 Canvas，内存占用就是 3840 * 2160 * 4 ≈ 33MB。如果你开了两个背景 Canvas，或者还有 WebGL 上下文，内存直接吃光。
错误写法 vs 正确写法
错误：未考虑 DPR，直接按 CSS 像素设置 Canvas 尺寸，导致模糊或内存误判；或者为了清晰盲目放大。
// 错误：简单粗暴地设置尺寸
const canvas = document.getElementById('bg-canvas');
const ctx = canvas.getContext('2d');
function resizeCanvas() {
// 只改了 CSS 尺寸，没改物理像素，或者物理像素设置错误
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
// 如果这里粒子数量固定为 5000，在 4K 屏上，
// 虽然画布大了，但粒子密度没变，看起来稀疏，
// 但更严重的是，如果代码里有逻辑是 每像素一个粒子，那内存直接爆
drawParticles(5000);
}
window.addEventListener('resize', resizeCanvas);
resizeCanvas();
正确：根据 DPR 动态调整，并限制粒子数量上限，使用离屏 Canvas 或降低分辨率。
// 正确：适配高分屏 + 性能保护
const canvas = document.getElementById('bg-canvas');
const ctx = canvas.getContext('2d', { alpha: false }); // 关闭 alpha，性能提升 20%
let particles = [];
const MAX_PARTICLES = 2000; // 硬性上限
function setupCanvas() {
const dpr = window.devicePixelRatio || 1;
const width = window.innerWidth;
const height = window.innerHeight;
// 物理尺寸 = CSS 尺寸 * DPR
canvas.width = width * dpr;
canvas.height = height * dpr;
canvas.style.width = width + 'px';
canvas.style.height = height + 'px';
// 关键：缩放上下文，让绘制逻辑仍基于 CSS 像素
ctx.scale(dpr, dpr);
// 性能优化：如果屏幕面积过大，减少粒子密度
const area = width * height;
let targetCount = Math.floor(area / 1000); // 每 1000 平方像素一个粒子
if (targetCount MAX_PARTICLES) {
targetCount = MAX_PARTICLES;
}
initParticles(targetCount);
}
function initParticles(count) {
particles = [];
for (let i = 0; i count; i++) {
particles.push({
x: Math.random() * window.innerWidth,
y: Math.random() * window.innerHeight,
vx: Math.random() * 2 - 1,
vy: Math.random() * 2 - 1,
size: Math.random() * 2 + 1
});
}
}
function drawFrame() {
ctx.clearRect(0, 0, window.innerWidth, window.innerHeight);
// 使用 requestAnimationFrame
particles.forEach(p = {
p.x += p.vx;
p.y += p.vy;
// 边界反弹
if (p.x 0 || p.x window.innerWidth) p.vx *= -1;
if (p.y 0 || p.y window.innerHeight) p.vy *= -1;
ctx.beginPath();
ctx.arc(p.x, p.y, p.size, 0, Math.PI * 2);
ctx.fillStyle = 'rgba(0, 255, 255, 0.5)';
ctx.fill();
});
requestAnimationFrame(drawFrame);
}
window.addEventListener('resize', setupCanvas);
setupCanvas();
requestAnimationFrame(drawFrame);
规避建议：
alpha: false：如果你的背景是不透明的，创建 2D Context 时务必加 { alpha: false }。这能让浏览器跳过混合操作，性能提升明显。
粒子上限：永远给粒子数量设一个 Hard Cap。大屏面积大，不代表你需要更多的粒子。用户感知不到 1000 个和 3000 个粒子的区别，但性能差很多。
离屏缓存：如果背景是静态的复杂图案，先在离屏 Canvas 画好，再 drawImage 到主 Canvas，避免每帧重绘复杂图形。
坑三：SVG 滤镜与模糊效果导致 GPU 过载
现象：背景使用了 filter 做模糊（blur）或发光（glow）效果。在 Chrome 上勉强能跑，换个 Firefox 或者老一点的显卡，直接卡成 PPT。有时候还会看到背景“闪烁”或“撕裂”。
根本原因：
SVG 滤镜（如 feGaussianBlur）是非常昂贵的操作。浏览器需要为滤镜创建一个独立的渲染通道，进行高斯卷积运算。
在大屏场景下，背景面积巨大。对一张 4K 的图片做 blur(10px)，计算量是惊人的。
更坑的是，很多兄弟为了省事，直接在 CSS 里写 filter: blur(5px) 在 img 或 div 上。这同样会触发 GPU 上的高斯模糊计算。如果这个元素还在动画中（比如缓慢移动），GPU 每帧都要重新计算模糊结果，显存带宽直接打满。
Stack Overflow 上有个经典问题：“CSS filter blur is slow on large images”，高票回答指出：模糊半径越大，性能损耗越高；图像面积越大，损耗越高。两者是乘法关系。
错误写法 vs 正确写法
错误：直接对大尺寸 DOM 元素应用 CSS filter 或 SVG filter。
!-- 错误：对大图直接加模糊，性能杀手 --
div class=bg-container
img src=huge-bg.png style=filter: blur(10px); transform: scale(1.1);
/div
正确：预渲染模糊背景，或者缩小源图像尺寸，或者使用 WebGL 实现模糊。这里推荐最通用的方案：预渲染 + 缩放补偿。
/* 正确：使用预模糊的图片，或者缩小图片后放大 */
.bg-pre-blurred {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-blurred.webp'); /* 这是提前用 ImageMagick 或代码生成的模糊图 */
background-size: cover;
background-position: center;
/* 不再使用 filter */
z-index: -1;
}
/* 如果必须动态模糊，缩小源图像尺寸 */
.bg-dynamic {
/* 使用小尺寸图，放大后自然模糊，或者用 CSS 缩放 */
width: 150vw;
height: 150vh;
top: -25vh;
left: -25vw;
background-image: url('bg-small.webp');
background-size: cover;
filter: blur(5px); /* 对小图做模糊，性能尚可 */
transform: scale(1);
}
代码生成预模糊背景（Node.js 示例）
const sharp = require('sharp');
async function generateBlurredBg() {
try {
await sharp('input-4k.jpg')
.resize(1920, 1080, { fit: 'cover' }) // 先缩小，减少模糊计算量
.blur(10) // 应用模糊
.toFile('output-bg-blurred.webp', { quality: 80 });
console.log('Blurred background generated successfully.');
} catch (err) {
console.error(err);
}
}
generateBlurredBg();
规避建议：
预渲染：凡是静态的模糊、发光背景，全部在构建阶段生成好，不要让用户端实时计算。
缩放技巧：如果必须用 CSS filter，确保源图像尺寸小于最终显示尺寸，利用缩放产生的模糊感，或者对缩小后的图像做模糊。
WebGL 替代：对于复杂的实时模糊、发光效果，上 WebGL 或 Three.js。GPU 着色器处理这些效果比 CPU 或 CSS Filter 高效几个数量级。
总结与自查清单
大屏背景的性能优化，核心就三点：减小数据量、分离合成层、避免实时计算。
图片格式：检查你的背景图是不是还是 JPG？换成 WebP/AVIF。
动画隔离：背景图本身别动，动效加在 overlay 上。
Canvas 适配：检查 DPR 处理，限制粒子数量，开启 alpha: false。
滤镜滥用：静态模糊预渲染，动态模糊慎用 CSS filter，复杂效果上 WebGL。
下次再遇到大屏卡顿，别急着换显卡，打开 Chrome DevTools 的 Performance 面板，录制 5 秒，看看是 Main Thread 忙（JS/重排），还是 Compositor 忙（重绘/合成），还是 GPU 忙（滤镜/3D）。对症下药，比盲目优化强一百倍。
你在项目里踩过这个坑吗？评论区聊聊，你是怎么解决大屏背景性能问题的？ 
长河君 · 2026/9/23 5:23:26 · 阅读 1.2k 大屏背景卡死？3个坑解决性能优化难题
大屏背景卡死？3个坑解决性能优化难题
前端做数据大屏，最怕什么？不是需求变，是屏幕一开就卡，刷新一下鼠标都动不了。更让人头秃的是，控制台红屏一片，StackTrace 长得像天书，看着报错一堆看不懂，心里慌得一批。很多兄弟第一反应是显卡不行，或者浏览器太老，其实十有八九，是你在大屏背景的处理上埋了雷。大屏背景看似只是几张图，但涉及渲染层合成、内存占用和重排重绘，稍有不慎，整个页面的性能优化就全完了。
今天咱们不整虚的，直接扒开大屏背景这三个最坑爹的问题。从现象到根因，从错误代码到正确写法，一步步带你避开这些坑。记住，大屏不是小页面，任何微小的性能损耗，在高分辨率下都会被放大十倍。
坑一：背景图无限重绘，CPU 飙升
现象：页面打开后，风扇狂转，温度飙升。打开任务管理器一看，Chromium 进程 CPU 占用率常年维持在 80%-100%。背景图明明没动，为什么一直在算？
根本原因：
很多兄弟喜欢用 background-image 加 background-size: cover 来铺满全屏。这本身没错，但问题出在“动效”上。如果你给背景图加了 transform: scale() 或者 animation，哪怕只是微小的缩放，浏览器就会判定该元素发生“重排”（Reflow）甚至“重绘”（Repaint）。
更隐蔽的坑是：背景图是 JPG 格式，且尺寸巨大（比如 4K 分辨率的图）。浏览器每帧都要解码这张图，然后进行光栅化（Rasterization）。如果背景层和其他内容层没有分离，每次页面有任何微小变化（比如数字跳动），浏览器都可能重新合成背景层。Stack Overflow 上有大量关于“Why is my CSS animation janky”的讨论，核心结论一致：不要在主线程做昂贵的位图操作。
错误写法 vs 正确写法
错误：直接用 JPG 大图做背景，并添加 CSS 动画。
/* 错误：JPG 大图 + CSS 动画，触发重绘 */
.dashboard-bg {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-4k.jpg'); /* 巨大的 JPG 文件 */
background-size: cover;
background-position: center;
/* 致命伤：这个动画会不断触发重绘 */
animation: pulse 4s infinite ease-in-out;
}
@keyframes pulse {
0% { transform: scale(1); }
50% { transform: scale(1.05); }
100% { transform: scale(1); }
}
正确：使用 WebP/AVIF 格式，且将动画隔离在独立合成层，或者使用 Canvas/WebGL 替代 CSS 动画。这里我们采用更稳妥的方案：静态背景 + 独立动效层。
/* 正确：静态背景，不动 */
.dashboard-bg {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-4k.webp'); /* 使用 WebP，体积更小，解码更快 */
background-size: cover;
background-position: center;
/* 关键：提升为独立合成层，避免与其他元素重排 */
will-change: transform;
z-index: -1;
}
/* 如果非要动效，加一个遮罩层或子元素做动画，而不是动背景图本身 */
.dashboard-bg-overlay {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background: radial-gradient(circle, rgba(255,255,255,0.1) 0%, rgba(0,0,0,0) 70%);
animation: overlayPulse 4s infinite ease-in-out;
pointer-events: none; /* 不阻挡交互 */
}
@keyframes overlayPulse {
0% { opacity: 0.8; }
50% { opacity: 1; }
100% { opacity: 0.8; }
}
规避建议：
格式转换：永远不要用 JPG 做大屏背景。转成 WebP 或 AVIF，体积能减 50% 以上，解码速度更快。
动静分离：背景图尽量保持静态。如果需要呼吸灯效果，加一个半透明的 overlay 层做 opacity 动画，opacity 动画不会触发重排，只触发合成（Composite），性能极佳。
will-change：给背景元素加上 will-change: transform，提前告诉浏览器“这货要动”，让它尽早创建 GPU 纹理。
坑二：Canvas 高分屏适配导致内存爆炸
现象：在 Retina 屏或 4K 显示器上，页面直接白屏，或者浏览器提示“内存不足，已终止脚本”。小屏幕正常，一上大屏就崩。
根本原因：
很多团队喜欢用 Canvas 画科技感线条、粒子背景。代码里写 canvas.width = window.innerWidth。
在普通屏（DPR=1）下，1920x1080 的 Canvas，像素数是 200 多万。
但在 4K 屏（DPR=2 或 3）下，为了清晰，你通常会把 Canvas 物理尺寸放大。如果 DPR=2，实际像素就是 3840x2160，再乘以 DPR 的平方？不，是乘以 DPR。但如果你处理不当，比如手动乘以了 DPR 两次，或者在高分屏上开了大量粒子，每个粒子都要绘制，内存占用呈指数级上升。
Canvas 是位图，它的内存占用 = 宽 × 高 × 4（RGBA）。一个 4K 的 Canvas，内存占用就是 3840 * 2160 * 4 ≈ 33MB。如果你开了两个背景 Canvas，或者还有 WebGL 上下文，内存直接吃光。
错误写法 vs 正确写法
错误：未考虑 DPR，直接按 CSS 像素设置 Canvas 尺寸，导致模糊或内存误判；或者为了清晰盲目放大。
// 错误：简单粗暴地设置尺寸
const canvas = document.getElementById('bg-canvas');
const ctx = canvas.getContext('2d');
function resizeCanvas() {
// 只改了 CSS 尺寸，没改物理像素，或者物理像素设置错误
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
// 如果这里粒子数量固定为 5000，在 4K 屏上，
// 虽然画布大了，但粒子密度没变，看起来稀疏，
// 但更严重的是，如果代码里有逻辑是 每像素一个粒子，那内存直接爆
drawParticles(5000);
}
window.addEventListener('resize', resizeCanvas);
resizeCanvas();
正确：根据 DPR 动态调整，并限制粒子数量上限，使用离屏 Canvas 或降低分辨率。
// 正确：适配高分屏 + 性能保护
const canvas = document.getElementById('bg-canvas');
const ctx = canvas.getContext('2d', { alpha: false }); // 关闭 alpha，性能提升 20%
let particles = [];
const MAX_PARTICLES = 2000; // 硬性上限
function setupCanvas() {
const dpr = window.devicePixelRatio || 1;
const width = window.innerWidth;
const height = window.innerHeight;
// 物理尺寸 = CSS 尺寸 * DPR
canvas.width = width * dpr;
canvas.height = height * dpr;
canvas.style.width = width + 'px';
canvas.style.height = height + 'px';
// 关键：缩放上下文，让绘制逻辑仍基于 CSS 像素
ctx.scale(dpr, dpr);
// 性能优化：如果屏幕面积过大，减少粒子密度
const area = width * height;
let targetCount = Math.floor(area / 1000); // 每 1000 平方像素一个粒子
if (targetCount MAX_PARTICLES) {
targetCount = MAX_PARTICLES;
}
initParticles(targetCount);
}
function initParticles(count) {
particles = [];
for (let i = 0; i count; i++) {
particles.push({
x: Math.random() * window.innerWidth,
y: Math.random() * window.innerHeight,
vx: Math.random() * 2 - 1,
vy: Math.random() * 2 - 1,
size: Math.random() * 2 + 1
});
}
}
function drawFrame() {
ctx.clearRect(0, 0, window.innerWidth, window.innerHeight);
// 使用 requestAnimationFrame
particles.forEach(p = {
p.x += p.vx;
p.y += p.vy;
// 边界反弹
if (p.x 0 || p.x window.innerWidth) p.vx *= -1;
if (p.y 0 || p.y window.innerHeight) p.vy *= -1;
ctx.beginPath();
ctx.arc(p.x, p.y, p.size, 0, Math.PI * 2);
ctx.fillStyle = 'rgba(0, 255, 255, 0.5)';
ctx.fill();
});
requestAnimationFrame(drawFrame);
}
window.addEventListener('resize', setupCanvas);
setupCanvas();
requestAnimationFrame(drawFrame);
规避建议：
alpha: false：如果你的背景是不透明的，创建 2D Context 时务必加 { alpha: false }。这能让浏览器跳过混合操作，性能提升明显。
粒子上限：永远给粒子数量设一个 Hard Cap。大屏面积大，不代表你需要更多的粒子。用户感知不到 1000 个和 3000 个粒子的区别，但性能差很多。
离屏缓存：如果背景是静态的复杂图案，先在离屏 Canvas 画好，再 drawImage 到主 Canvas，避免每帧重绘复杂图形。
坑三：SVG 滤镜与模糊效果导致 GPU 过载
现象：背景使用了 filter 做模糊（blur）或发光（glow）效果。在 Chrome 上勉强能跑，换个 Firefox 或者老一点的显卡，直接卡成 PPT。有时候还会看到背景“闪烁”或“撕裂”。
根本原因：
SVG 滤镜（如 feGaussianBlur）是非常昂贵的操作。浏览器需要为滤镜创建一个独立的渲染通道，进行高斯卷积运算。
在大屏场景下，背景面积巨大。对一张 4K 的图片做 blur(10px)，计算量是惊人的。
更坑的是，很多兄弟为了省事，直接在 CSS 里写 filter: blur(5px) 在 img 或 div 上。这同样会触发 GPU 上的高斯模糊计算。如果这个元素还在动画中（比如缓慢移动），GPU 每帧都要重新计算模糊结果，显存带宽直接打满。
Stack Overflow 上有个经典问题：“CSS filter blur is slow on large images”，高票回答指出：模糊半径越大，性能损耗越高；图像面积越大，损耗越高。两者是乘法关系。
错误写法 vs 正确写法
错误：直接对大尺寸 DOM 元素应用 CSS filter 或 SVG filter。
!-- 错误：对大图直接加模糊，性能杀手 --
div class=bg-container
img src=huge-bg.png style=filter: blur(10px); transform: scale(1.1);
/div
正确：预渲染模糊背景，或者缩小源图像尺寸，或者使用 WebGL 实现模糊。这里推荐最通用的方案：预渲染 + 缩放补偿。
/* 正确：使用预模糊的图片，或者缩小图片后放大 */
.bg-pre-blurred {
position: fixed;
top: 0;
left: 0;
width: 100vw;
height: 100vh;
background-image: url('bg-blurred.webp'); /* 这是提前用 ImageMagick 或代码生成的模糊图 */
background-size: cover;
background-position: center;
/* 不再使用 filter */
z-index: -1;
}
/* 如果必须动态模糊，缩小源图像尺寸 */
.bg-dynamic {
/* 使用小尺寸图，放大后自然模糊，或者用 CSS 缩放 */
width: 150vw;
height: 150vh;
top: -25vh;
left: -25vw;
background-image: url('bg-small.webp');
background-size: cover;
filter: blur(5px); /* 对小图做模糊，性能尚可 */
transform: scale(1);
}
代码生成预模糊背景（Node.js 示例）
const sharp = require('sharp');
async function generateBlurredBg() {
try {
await sharp('input-4k.jpg')
.resize(1920, 1080, { fit: 'cover' }) // 先缩小，减少模糊计算量
.blur(10) // 应用模糊
.toFile('output-bg-blurred.webp', { quality: 80 });
console.log('Blurred background generated successfully.');
} catch (err) {
console.error(err);
}
}
generateBlurredBg();
规避建议：
预渲染：凡是静态的模糊、发光背景，全部在构建阶段生成好，不要让用户端实时计算。
缩放技巧：如果必须用 CSS filter，确保源图像尺寸小于最终显示尺寸，利用缩放产生的模糊感，或者对缩小后的图像做模糊。
WebGL 替代：对于复杂的实时模糊、发光效果，上 WebGL 或 Three.js。GPU 着色器处理这些效果比 CPU 或 CSS Filter 高效几个数量级。
总结与自查清单
大屏背景的性能优化，核心就三点：减小数据量、分离合成层、避免实时计算。
图片格式：检查你的背景图是不是还是 JPG？换成 WebP/AVIF。
动画隔离：背景图本身别动，动效加在 overlay 上。
Canvas 适配：检查 DPR 处理，限制粒子数量，开启 alpha: false。
滤镜滥用：静态模糊预渲染，动态模糊慎用 CSS filter，复杂效果上 WebGL。
下次再遇到大屏卡顿，别急着换显卡，打开 Chrome DevTools 的 Performance 面板，录制 5 秒，看看是 Main Thread 忙（JS/重排），还是 Compositor 忙（重绘/合成），还是 GPU 忙（滤镜/3D）。对症下药，比盲目优化强一百倍。
你在项目里踩过这个坑吗？评论区聊聊，你是怎么解决大屏背景性能问题的？