How to lazy load an Instagram feed on your website (and what our widget already does)

The short answer

You do not need a plugin or extra code to lazy load the images in a Social Feed by grip space widget. The widget already uses the browser’s native lazy loading, the loading="lazy" attribute on each image, in the way that suits each layout:

What you control is how many images the feed contains, which layout it uses and where on the page it sits. Those three choices decide how much the feed adds to the first load of your page. The rest of this post explains why.

What lazy loading is

Normally a browser downloads every image in a page as soon as it finds it in the HTML, whether the image is at the top of the page or ten screens further down. That is called eager loading, and it is the default.

Lazy loading changes this for images that are far from what the visitor can see. The browser notes that the image exists, reserves its space if the size is known, and only starts the download when the visitor scrolls close enough. Visitors who never scroll that far never download those images at all.

For a page with an Instagram feed near the bottom, that can make a real difference. A grid of 24 photos at the end of a long homepage costs visitors who only read the top section almost nothing, because most of those photos are never requested.

Native lazy loading: the loading attribute

Modern browsers support lazy loading directly in HTML, with no JavaScript library. You add one attribute to the image:

<img src="photo.jpg" width="800" height="600" loading="lazy" alt="…">

MDN Web Docs describes the two values like this:

1. eager loads the image immediately, whether or not it is in the visible part of the page. This is the default.
2. lazy defers loading the image until it reaches a distance from the viewport that the browser calculates.

A few details from the official documentation are worth knowing:

1. “Near the viewport” is decided by the browser. Google’s web.dev article on lazy loading says Chrome uses distance thresholds that depend on the connection: 1,250 pixels on a 4G connection and 2,500 pixels on 3G or slower. These values cannot be changed by the page. In other words, a lazy image starts loading a bit before it comes into view, not at the moment it appears.
2. It works almost everywhere. According to web.dev, image lazy loading is supported in Chrome 77, Edge 79, Firefox 75 and Safari 15.4 and later. Older browsers simply ignore the attribute and load the image normally, so nothing breaks.
3. It only applies when JavaScript is enabled. MDN explains that this is an anti-tracking measure. For a feed widget this never matters, because the widget itself needs JavaScript to appear.
4. Lazy images need a size. MDN warns that an image with no width and height has a size of zero until it loads, which can cause it never to load or make content jump when it does. Width and height, or CSS that gives the image a box, solve this.
5. Do not lazy load what is visible at the start. web.dev recommends keeping images that are visible when the page first loads, especially the page’s largest image, on eager loading. Lazy loading them only delays them.

How Social Feed by grip space uses it

The widget builds its images with JavaScript when the page loads, and sets the loading attribute on each one. Here is what happens in each part of the feed.

Grid layout: the first row right away, the rest lazily

In the grid, the widget gives the first images eager loading and all later images lazy loading. The number of eager images is the number of columns you set in “Settings & preview”. With 4 columns, images 1 to 4 load right away and images 5 onward are lazy. With 6 columns, images 1 to 6 are eager.

The reason is simple: the first row is the part of the feed most likely to be seen first, and if it were lazy, visitors who scroll quickly to the feed would see empty tiles for a moment. Everything below the first row can wait.

One detail matters on phones. The widget reduces the number of columns automatically when the space is narrow, so that each tile stays at least about 100 pixels wide. The eager count still follows the number you set, not the number shown. If you set 6 columns and a phone shows 3, the first 6 images, two rows on that phone, load right away. That is a small cost, but it is one reason not to set a high column count without a reason. The guide to grid and slider layouts explains how columns adapt to the width.

Every tile is a square with a fixed shape, and the image fills the tile. Because the tile already has its size before the image arrives, lazy images have a box to load into, and the grid does not jump as images appear. MDN’s warning about images without a size does not apply here.

Slider layout: every image right away

In the slider, all images are eager. This is deliberate. A slider shows one row and moves sideways when a visitor swipes or clicks an arrow. In our testing, lazy images in a sideways row could still be blank when the visitor arrived at them after an arrow click, which looks broken. Loading the whole row up front avoids that.

web.dev notes that since Chrome 121, images in horizontally scrolling containers use the same thresholds as vertical scrolling, so they load earlier than they used to. That narrows the gap between the two approaches in Chrome, but other browsers behave differently, and a blank tile after a swipe is a worse experience than a few extra downloads.

The practical consequence: a slider’s cost is the full number of posts it contains. A slider with 12 posts downloads 12 images for every visitor, even those who never swipe. Keep sliders modest, usually 10 to 20 posts. If you want to show many posts, a grid is the lighter option.

Lightbox, videos and carousel posts: loaded on demand

The tiles only show a single image per post. Larger media loads only when a visitor asks for it:

1. The lightbox is built when a visitor clicks a tile. Its image is requested at that moment, not when the page loads. If you set clicks to open Instagram or to do nothing, there is no lightbox at all.
2. Videos and Reels appear on the tile as their cover image. The video file is not part of the page until a visitor opens the post in the lightbox, where it starts playing with the sound off. A feed full of Reels therefore does not download video when the page loads. See showing Instagram videos on your website for more on how videos behave.
3. Carousel posts show their first image on the tile. If you choose to show all images of a carousel in the lightbox, the second and later images are each requested only when the visitor moves to them with the arrows. A carousel with ten photos does not add ten downloads to your page. The post on carousel posts on your website covers the display settings.

What a feed costs at first load, by setup

Putting this together, here is how many feed images a visitor downloads before scrolling, assuming the feed is far enough down the page that its lazy images are outside the browser’s threshold:

If the feed sits close to the top of the page, within the browser’s threshold, the browser will start loading the lazy images as well, because they count as “near” the viewport. Lazy loading helps most when the feed is well down the page.

Remember that the account header’s profile picture is one more image when the header is on. The images themselves come directly from Instagram’s image servers, at the size Instagram provides.

Choosing settings with loading in mind

1. Prefer a grid for large feeds. A 24-post grid costs a row of images at first; a 24-post slider costs 24.
2. Set only as many columns as you need. More columns means more eager images in the grid, even on phones that show fewer.
3. Keep sliders short. 10 to 20 posts is plenty for most pages, since every one of them loads at first.
4. Place the feed below your main content. A feed far down the page benefits fully from lazy loading. See where to put an Instagram feed on your website for placement ideas by page.
5. Use the post count you actually need. On the Free plan the maximum is 16 posts, on the Light plan 30 and on the Standard plan 50. A higher maximum is a ceiling, not a target.

Do not make the feed your page’s largest element

Largest Contentful Paint (LCP), one of Google’s Core Web Vitals, measures when the largest image or text block in the visible part of the page appears. web.dev considers 2.5 seconds or less a good LCP.

A feed is added by a script, so its images appear after the script has loaded and run. If the feed is at the very top of the page and one of its tiles is the largest thing on screen, that tile becomes the LCP element and is limited by how fast the script arrives. Put your own main image or heading at the top instead, and the feed lower down. The widget’s first-row images are already eager, so making them “more eager” is not possible from your side; the fix is placement.

Placement also matters for layout shift. The feed’s space on the page is created when the script runs, so content below it moves down once the feed appears. Lazy loading does not cause this shift (each tile has its size before its image loads), but where you put the feed decides how much of your page moves. Our post on where to place a widget script explains the role of the script tag itself.

Can I change which images are lazy?

There is no setting to switch lazy loading on or off, or to change how many images are eager. The behavior is built into each layout because the alternatives are worse: lazy images in the slider can show blank tiles, and a lazy first row in the grid can show blank tiles to visitors who arrive at the feed quickly.

You also should not try to add loading attributes yourself. The images are created by the widget’s script, not by your HTML, so there is nothing in your page to edit. Optimization plugins that rewrite images in your HTML cannot see the feed’s images either, and they do not need to.

What does help is the set of choices above: layout, columns, post count and placement.

Feeds inside tabs, accordions and pop-ups

Some sites place the feed inside a tab, an accordion or a modal that is hidden when the page loads. web.dev notes that Chrome, Safari and Firefox do not load images hidden with display: none, on the image itself or on a parent element. In that situation, lazy images in the feed generally wait until the hidden section is opened, which is usually what you want.

Hiding with other techniques, such as setting the opacity to zero, does not stop images from loading. If your theme hides sections in an unusual way, check the result with the steps below rather than assuming.

How to check lazy loading on your own page

You can see exactly what loads, and when, with the developer tools built into Chrome (other browsers have similar tools):

1. Open the published page, not the editor preview. Many editors do not run scripts the way the live site does.
2. Open DevTools with Command+Option+J on a Mac or Control+Shift+J on Windows, and click the Network tab. DevTools only records requests while it is open.
3. Click the Img filter if your toolbar shows it, so only images are listed.
4. Reload the page without scrolling. Long-press the reload button and choose “Empty Cache and Hard Reload” to make sure images come from the network, not from the cache.
5. Look at the image requests from Instagram’s servers. In a grid placed well down the page, you should see about as many feed images as the number of columns you set, plus the profile picture if the header is on.
6. Now scroll slowly toward the feed. New image requests appear as you approach the lower rows.
7. To see the attribute itself, right-click a tile, choose Inspect, and look at the img element. Later tiles in a grid show loading="lazy"; first-row tiles and all slider tiles show loading="eager".

To see how this feels on a slow connection, choose a slower option such as 3G in the Network panel’s throttling menu and scroll through the feed. Lazy images should load a little before they appear, as the threshold is larger on slower connections.

Troubleshooting

Tiles stay gray for a moment when I scroll. Each tile has a light gray background until its image arrives. On a fast connection that moment is usually too short to notice; on a slow one it can be visible. This is the normal trade-off of lazy loading. If it bothers you on a short page, a slider loads all images up front instead.

All images load at once in the grid. Check whether the feed is close to the top of the page, within the browser’s distance threshold. Also check that you are not looking at the slider layout, where all images are eager by design.

Images never load at all. That is not a lazy-loading issue. The usual causes are a Content Security Policy that does not allow images from Instagram’s servers, a browser extension that blocks them, or a script that never ran. See why an Instagram feed is not showing on your website for the full checklist.

Lazy loading and SEO

A feed’s images are loaded from Instagram’s servers and are not what usually ranks your page, so lazy loading them does not take anything away from your search visibility. Our post does an Instagram feed help SEO? covers what Google can and cannot see in a feed.

Frequently asked questions

Do I need a lazy-loading plugin for my Instagram feed? Not for Social Feed by grip space. The widget already uses the browser’s native lazy loading in the grid, and loads lightbox images, videos and extra carousel images only on demand.

Why does the slider not use lazy loading? Because a sideways row moved with arrows can reach a lazy image before it has loaded, which shows an empty tile. Loading the row up front avoids that. Keep sliders to a modest number of posts.

Does lazy loading work on iPhone? Yes. web.dev lists Safari 15.4 as the first version that supports image lazy loading. Older versions ignore the attribute and load images normally.

Will lazy loading make my feed show fewer posts? No. Every post is in the feed from the start; only the download of the image waits. The number of posts is set by your post count, filters and plan.

Are videos downloaded when the page loads? No. Tiles show the cover image only. The video loads when a visitor opens the post in the lightbox.

Does lazy loading change the view count in my dashboard? No. A view is counted when the widget loads on a page, not when its images load. A visitor who never scrolls down to the lower rows of a grid still counts as one view, the same as a visitor who scrolls through every post. Keep this in mind on the Free plan, which includes 3,000 views a month.

Does the widget use a JavaScript lazy-loading library? No. It sets the standard loading attribute and lets the browser decide when to load each image.

Ready to try it? You can create a free account and add a feed in a few minutes, or compare plans on the pricing section. For step-by-step setup, see the guides for WordPress, Shopify, Wix, Squarespace, Webflow and plain HTML.

Sources

1. Google web.dev, “Browser-level image lazy loading for the web”: https://web.dev/articles/browser-level-image-lazy-loading
2. MDN Web Docs, “<img>: The Image Embed element” (loading attribute): https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/img
3. Chrome for Developers, “Inspect network activity”: https://developer.chrome.com/docs/devtools/network
4. Google web.dev, “Largest Contentful Paint (LCP)”: https://web.dev/articles/lcp