这事儿，说起来就来气，真是把我折腾得够呛，但搞定了，心里那叫一个舒坦！
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.icu
话说有那么一阵子，我的几个网站用户反馈说访问页面很慢，尤其是图片半天出不来。平时挺佛系的，但遇到用户抱怨网站卡顿，那可真是坐不住了。当时就觉得一头雾水，我自己的服务器配置不差，带宽也够用，代码也反复检查了，该做的优化都做了，网站的图片也都压缩处理过了，怎么还会慢？
刚开始的时候，我真以为是自己哪里又搞砸了。那几天，我真是茶不思饭不想的。晚上做梦都是服务器在报警，然后我就在梦里敲代码，查日志，反正把自己搞得一团糟。我把网站前前后后、里里外外地翻了个底朝天，从前端的JS、CSS到后端的数据库查询，一个个地排查过去，日志翻了一页又一页，性能分析工具也跑了好几遍，结果？我的代码基本上没啥大问题，服务器跑得也稳稳当当的。
那问题到底出在哪儿了？我当时头都大了，坐在电脑前，看着用户反馈里一句句“卡死”、“图片不显示”，心里那个急，差点没把我急死。后来我灵机一动，打开了浏览器的开发者工具，切换到“网络”那个页签，刷新了一下页面，仔细盯着加载的每一个请求。
好家伙！这一看不要紧，真是把我吓一跳！我发现页面加载的时候，卡住的请求大多都指向了一个陌生的域名——。我的天呐，这可不是我自己的域名！仔细一瞅，原来是网站里用到的一些表情包、用户头像，还有一些从第三方接口获取的带图片内容，它们的图片地址都指向了这里。这些东西虽然不是我直接上传的，但因为我的页面要依赖它们显示出来，如果它们加载慢，整个页面不就跟着一块儿慢了吗？当时我就感觉找到了“罪魁祸首”，但又特别无奈，这玩意儿又不归我管，我能怎么办？
找到问题源头，我就开始琢磨对策了。一开始想了好几种办法，真是有点病急乱投医的感觉。我寻思着要不要把所有图片都自己存一份，但是一想，那得多大的存储空间，而且很多是用户动态发的，我总不能自己去下载再上传，这成本太高，太不现实了！
后来又试着在网站的HTML头部加了一些资源提示，比如，想着能不能让浏览器提前建立连接，减少等待时间。虽然理论上这能快那么一点点，但实际上，对于页面图片特别多的情况，效果真是一般般，页面该慢还是慢，治标不治本。我也检查了一下，是不是我引用了太多大图导致的问题，但很多图也是第三方接口直接返回的，我没法直接改。
折腾了一圈，效果都不太理想，我当时真是有点灰心。但这问题总不能不管？用户还在抱怨。晚上躺床上翻来覆去睡不着，突然脑子里灵光一闪，我想到了“懒加载”这回事儿！既然我不能控制的加载速度，那我总能控制我的页面什么时候去请求它的资源？用户又不是一打开页面就把所有图片都看完了，对不对？
于是我第二天一早爬起来，说干就干。我的想法是这样的：
-
第一步：找到那些需要懒加载的图片。 我把页面上所有可能用到链接的图片标签都筛选了出来。这些图片一开始就不用加载，等到用户滚动到它们的时候再加载。
-
第二步：修改HTML结构。 我把这些图片标签的
src属性都改成了data-src。比如原来是<img src="*/*">，我就改成了<img data-src="*/*">。这样一来，浏览器在解析页面的时候就不会主动去加载这些图片了。 -
第三步：编写JavaScript代码。 这是最关键的一步。我写了一小段JS代码，主要就是做两件事。它会监听页面的滚动事件，当用户滚动页面的时候，代码就会检查哪些图片进入了用户的可视区域。一旦发现有图片进入可视区域，它就会把这个图片的
data-src属性里的值取出来，赋值给它的src属性。这样浏览器才真正开始加载这张图片。 -
第四步：加个兼容性处理和占位符。 为了让效果更我还加了点小细节。比如说，对于支持
Intersection Observer API的现代浏览器，我就用这个更高效的API来监听图片是否可见。对于老一点的浏览器，就用传统的滚动监听和getBoundingClientRect()方法来判断。在图片还没加载出来的时候，为了不让页面太空，我还给这些图片加了一个小小的占位符或者一个低像素的模糊图，让用户体验好一些。
我改完这些代码，忐忑地部署到线上，然后自己打开网站测试。我的天呐！刷新页面的一瞬间，我真是惊呆了！以前要等好几秒才能出来的页面，现在几乎是秒开！页面内容一下子就出来了，那些图片，也是随着我滚动页面，才一张张地“冒”出来。那种感觉，就像是给网站卸下了一个沉重的包袱，一下子轻盈起来！用户再也没抱怨过卡顿了，老板也没再问过我网站速度的问题了，当时心里那个美！
这事儿，让我深刻地明白了一个道理：遇到这种你控制不了的外部资源问题，不能光盯着对方“唉声叹气”，得想办法优化自己这边的策略。很多时候，问题看着复杂，但解决起来可能就是换个思路。懒加载这个东西，看着简单，用对地方，真是神兵利器，一下子就把我的难题给解决了！