{"id":21844,"date":"2019-02-11T17:25:06","date_gmt":"2019-02-11T17:25:06","guid":{"rendered":"http:\/\/a_chaotic_good_guide_to_image_performance_part_2"},"modified":"2022-02-26T04:00:15","modified_gmt":"2022-02-26T04:00:15","slug":"a_chaotic_good_guide_to_image_performance_part_2","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/a_chaotic_good_guide_to_image_performance_part_2","title":{"rendered":"A Chaotic Good Guide to Image Performance, Part 2"},"content":{"rendered":"

Part 1<\/a> of this series delves into the background for this guide. Here in part 2 are the ins and outs.<\/p>\n

\u201cJust get rid of some images.\u201d<\/h3>\n

Wait, hear me out. I know, we just talked about this: Nobody is sheepishly pleading you, \u201cPlease, might we have just one more<\/em> image on the page?\u201d No, I\u2019m not telling you to pick that particular fight. Instead, use a little smoke and mirrors to avoid requests for images that your audience needn\u2019t render right away and might never need at all while loading them asynchronously\u2014only as needed.<\/p>\n

Until a few years ago, nothing much had changed about img<\/code> since its inception back in December 1992. For the most part, if your markup contained an image with an src<\/code> attribute, the browser wouldn\u2019t give you any choice: It would request and transfer that image ASAP. To avoid or defer an image request the audience might not see in some contexts<\/a>, removing it from the page was your only option. Even during the earliest days of prototyping potential \u201cresponsive images\u201d solutions, it was clear that img<\/code> would benefit from more flexibility because loading images asynchronously, that is, only when scrolled into view, was a convoluted process. Listening to scroll events is expensive, likewise for listening for the resizing of the browser window. Determining whether an image had scrolled into view would mean doing both while checking and rechecking the position of each image on the page. Such a task was labor-intensive, let alone that the results were always\u2014pardon my candor\u2014pretty janky.<\/p>\n

Fast forward to the present day, and we have the experimental Intersection Observer API<\/a>. As its name implies, IntersectionObserver<\/code> enables us to efficiently observe if the elements visibly intersect with the browser viewport and, if so, are visible online. When applied to img<\/code>, the API presents a simple, powerful, and largely seamless way to avoid unnecessary image requests.<\/p>\n

With only a few lines of code, we can put together a script that asynchronously requests images only when they intersect with the audience\u2019s viewport. No fuss, no muss, and hardly anything for us to manage:<\/p>\n