懒加载的核心目的是提升网页初始加载速度和用户体验，减少不必要的资源消耗，其最推荐的实现方式是结合html的loading="lazy"属性和javascript的intersection observer api。对于图片和iframe，可直接使用原生loading="lazy"实现高效懒加载；对于背景图、视频、自定义组件等复杂场景，则应采用intersection observer api异步监听元素进入视口的时机，动态加载资源，避免主线程阻塞。懒加载解决了传统全量加载导致的首屏渲染慢、带宽浪费、服务器压力大等问题，显著提升fcp和lcp指标，优化移动端流量消耗与交互流畅度。除图片外，视频、spa组件、长列表数据、非关键css/js文件及背景图均可实施懒加载。但需注意其潜在缺点：可能影响seo（需确保爬虫可抓取data-src内容或使用noscript备用方案）、引发布局偏移（cls，需预设元素尺寸或使用aspect-ratio）、依赖javascript（原生方案可缓解）、误用于首屏内容导致加载延迟，以及老旧浏览器兼容性问题（需polyfill）。因此，应根据内容重要性、用户行为和浏览器支持情况合理应用懒加载策略，以实现性能与体验的平衡。
懒加载，说白了，就是一种延迟加载策略。它不是一股脑儿把所有内容都加载出来，而是等到用户真正需要看到某个元素时（比如滚动到屏幕可见区域），才去加载它。这就像你点外卖，店家不是把所有菜都提前做好，而是等你下单了才开始准备，这样既节省了资源，也保证了新鲜度。核心目的就是提升网页的初始加载速度和用户体验，减少不必要的资源消耗。
懒加载的实现，在我看来，最现代也最推荐的方式是利用浏览器原生的能力或者
Intersection Observer API。
解决方案
实现懒加载，最直接且效率高的方案是结合HTML属性和JavaScript的
Intersection Observer API。
1. 原生懒加载（针对图片和iframe）： 现代浏览器已经支持原生的
loading属性。你只需要在
@@##@@或
2. JavaScript的Intersection Observer API： 对于更复杂的场景，比如背景图、视频、自定义组件或者需要更精细控制的元素，
Intersection Observer API是首选。它提供了一种异步观察目标元素与祖先元素或视窗交叉状态的方法。这比传统的监听
scroll事件和计算元素位置要高效得多，因为它不会在主线程上频繁触发，避免了性能瓶颈。
基本思路是：
- 给所有需要懒加载的元素一个占位符或者统一的CSS样式，防止页面布局跳动（Cumulative Layout Shift, CLS）。
- 在HTML中，将实际的资源路径存储在非标准属性中，比如
data-src
。 - 创建一个
Intersection Observer
实例，并给它一个回调函数。 - 遍历所有需要懒加载的元素，将它们添加到观察器中。
- 当元素进入视口时，回调函数触发，我们将
data-src
中的路径赋值给src
属性，然后停止观察这个元素。
document.addEventListener("DOMContentLoaded", function() {
const lazyImages = document.querySelectorAll('img[data-src], iframe[data-src]'); // 也可以是其他元素
const observerOptions = {
root: null, // 默认为视口
rootMargin: '0px', // 元素进入视口多少距离触发回调
threshold: 0.01 // 元素可见比例达到1%时触发
};
const imageObserver = new IntersectionObserver((entries, observer) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const lazyElement = entry.target;
if (lazyElement.dataset.src) { // 检查是否有data-src属性
lazyElement.src = lazyElement.dataset.src;
if (lazyElement.tagName === 'SOURCE') {
// 对于 内部的 标签，需要父级 重新评估
// 或者直接处理 @@##@@
}
}
if (lazyElement.dataset.srcset) {
lazyElement.srcset = lazyElement.dataset.srcset;
}
// 如果是背景图，可能需要通过修改style来实现
if (lazyElement.dataset.bg) {
lazyElement.style.backgroundImage = `url(${lazyElement.dataset.bg})`;
}
observer.unobserve(lazyElement); // 停止观察已加载的元素
}
});
}, observerOptions);
lazyImages.forEach(image => {
imageObserver.observe(image);
});
}); 当然，实际项目中，你可能还需要考虑错误处理、加载中的占位图、以及加载失败的提示。
为什么我们需要懒加载？它解决了什么痛点？
说实话，这个问题问得很好，因为懒加载的核心价值就在于它解决了一系列前端开发中长期存在的“痛点”。最直接的，就是页面加载速度。想象一下，一个电商网站有上百张商品图片，如果用户一打开页面就全部加载，那用户体验简直是灾难性的。白屏时间会很长，用户可能还没看到内容就直接关掉了。
懒加载的出现，就是为了避免这种“一次性加载所有”的低效模式。它让页面在初次加载时只加载用户当前屏幕可见区域的内容，其余的，等用户滚动到相应位置再加载。这带来了几个显而易见的优势：
- 提升首屏加载速度（FCP & LCP）：这是最显著的优势。用户能更快地看到页面的主要内容，大大提升了用户的第一印象和留存率。
- 降低服务器压力和带宽消耗：不是所有用户都会浏览完整个页面，懒加载意味着服务器不必为那些从未被用户看到的内容发送数据，从而减少了不必要的资源传输。这对于移动设备用户尤其友好，能节省他们的流量。
- 优化资源利用：浏览器不必同时处理大量的图片解码和渲染任务，可以更专注于当前可见内容的渲染，使得页面响应更流畅。
- 改善用户体验：虽然有些用户可能察觉不到技术细节，但他们能感受到页面“轻”了，“快”了，这本身就是极大的体验提升。那种滚动时图片逐渐显现的效果，也挺有意思的。
除了图片和iframe，还有哪些内容可以懒加载？
很多人一提到懒加载，脑子里第一反应就是图片和iframe，这确实是懒加载最常见的应用场景。但实际上，懒加载的应用范围远不止于此，任何非首屏关键的、按需加载的资源，都可以考虑懒加载。
-
视频元素 ()：大型视频文件如果一开始就加载，那带宽消耗和加载时间会非常恐怖。将视频的
src
属性延迟加载，或者只加载海报图，等用户点击播放或滚动到视口时再加载视频流，是常见的优化手段。 - 组件或模块：在单页应用（SPA）中，某些组件可能只在特定条件下（比如用户点击某个按钮，或者滚动到页面底部）才需要显示。这时，可以使用Webpack等打包工具的代码分割（Code Splitting）配合动态导入（Dynamic Import），实现组件级别的懒加载。只有当用户需要时，才去下载和解析对应的JavaScript和CSS文件。
- 长列表数据（无限滚动）：在社交媒体、电商列表等场景，用户向下滚动时，新的内容会不断加载进来。这其实就是数据懒加载的一种形式。通常是通过监听滚动事件，当用户接近列表底部时，触发API请求，获取更多数据并渲染。
- CSS和JavaScript文件：虽然不常见，但对于某些非关键的、只在特定交互后才需要的CSS或JS文件，也可以考虑延迟加载。例如，一个复杂的弹窗组件的样式和逻辑，可以在用户点击按钮打开弹窗时再动态加载。不过，这需要非常谨慎地评估，因为处理不当可能导致布局闪烁或功能延迟。
-
背景图片：通过CSS设置的背景图片，也可以通过JavaScript判断元素是否进入视口，然后动态添加或修改
background-image
属性来实现懒加载。
总的来说，只要是“非立即必需”的资源，我们都可以考虑把它放到懒加载的范畴里。
懒加载有没有潜在的缺点或需要注意的地方？
任何优化策略都不是银弹，懒加载也不例外。它确实能带来显著的性能提升，但在实际应用中，如果处理不当，也可能引入一些新的问题。
首先，SEO问题。虽然现代搜索引擎（尤其是Google）的爬虫已经足够智能，能够执行JavaScript并识别
loading="lazy"属性，但对于一些老旧的爬虫或者不那么智能的搜索引擎，它们可能无法抓取到那些通过JavaScript延迟加载的图片或内容。这意味着你的图片可能不会被索引，从而影响图片搜索排名。解决办法是，确保
data-src中的内容在HTML源代码中是可访问的，或者为关键图片提供
srcset和
sizes属性，并辅以
noscript标签作为备用方案。
其次，是用户体验上的细微瑕疵，特别是布局偏移（Cumulative Layout Shift, CLS）。当图片或其他元素在加载完成之前没有预留足够的空间时，它们在加载完成后可能会突然撑开页面，导致页面内容跳动，这会给用户带来糟糕的体验。解决这个问题的关键是，在懒加载元素加载之前，为其预留确切的尺寸（通过CSS设置
width和
height，或者使用
aspect-ratio属性）。
再者，对JavaScript的依赖。如果用户的浏览器禁用了JavaScript，或者JavaScript文件加载失败，那么那些依赖JavaScript进行懒加载的元素就永远不会被加载出来。这也是为什么原生
loading="lazy"属性如此重要的原因，因为它在没有JavaScript的情况下也能工作。对于关键内容，我们通常会提供一个
noscript标签或者一个默认的占位符。
还有就是“折叠之上”（Above the Fold）的内容。对于用户一打开页面就能看到的内容，我们不应该使用懒加载。这些内容应该立即加载，以确保最快的首屏渲染。如果对折叠之上的内容也进行了懒加载，反而会拖慢用户看到核心信息的速度，适得其反。
最后，浏览器兼容性。虽然
Intersection Observer和原生
loading="lazy"的兼容性已经很不错了，但对于一些非常老的浏览器，你可能需要引入Polyfill或者退回到传统的
scroll事件监听方案。这增加了开发的复杂性，并且传统方案的性能远不如现代API。
所以，在决定是否以及如何实施懒加载时，需要综合考虑项目的具体需求、目标用户群体以及对SEO和用户体验的潜在影响，而不是盲目地全部应用。
