Core Web Vitals and third-party embeds: a practical guide for small sites

Core Web Vitals in one minute

Core Web Vitals are three metrics that Google’s web.dev site describes as measuring loading, interactivity and visual stability. Each has a threshold for a “good” experience:

Two details matter when you read your own results. First, web.dev recommends judging each metric at the 75th percentile of page loads, separately for mobile and desktop. A page passes when three out of four visits meet the target, not when your own fast laptop does. Second, INP replaced an older metric, First Input Delay (FID), and became a stable Core Web Vital in 2024. Older articles and tools that talk about FID are out of date.

If you’re wondering whether any of this affects search, our article does an Instagram feed help SEO? covers what Google says about page experience and rankings. This guide focuses on the mechanics and the fixes.

How an embed gets onto your page

Almost every embed follows the same pattern. You paste a snippet, usually a script tag or an iframe. When a visitor loads the page, the browser fetches the provider’s code, runs it, and the code adds content: images, video, text or a whole framed page. That process costs three things, and each maps neatly onto one metric:

The size of each cost depends on the embed. An iframe-based embed loads a whole separate page. web.dev’s article on embed best practices notes, for example, that Instagram’s own post embed script injects an iframe that can exceed 100 KB gzipped. A lighter script that writes images directly into your page avoids the separate page, but still downloads images and still adds content after the page has started to display.

LCP: when embeds slow down the main content

LCP looks at the largest element visible in the viewport while the page loads. According to web.dev, the eligible elements include images, the poster or first frame of a video, elements with a CSS background image, and blocks of text. Only what is in view counts, so an embed far down the page isn’t a candidate when the page first loads.

An embed affects LCP in two ways:

1. The embed becomes the LCP element. If a feed, video or large widget sits near the top of the page, one of its images may be the largest thing in view. Embed images arrive late by nature: first the script must download and run, and only then can the image request start. An image written directly into your page’s HTML starts loading much earlier.
2. The embed delays your own LCP element. Even when your hero image or headline is the LCP element, an embed placed above it in the page’s code, or one that downloads a lot at the start, competes for bandwidth and processing time.

web.dev’s guidance on lazy loading adds a rule worth remembering: don’t lazy-load images that are likely to be in view when the page loads, especially the LCP image. Lazy loading is for content further down. That applies to your own images and to how you judge an embed’s settings.

INP: when embeds make the page feel sluggish

INP watches the clicks, taps and key presses a visitor makes during the whole visit and reports a value that most of those interactions fall beneath. web.dev splits each interaction into three phases:

Hovering, scrolling and zooming aren’t counted, according to web.dev. Clicking a menu, a button or a tile in a feed is.

The most common way embeds hurt INP on small sites is input delay during loading. Several scripts download and run at once: analytics, a chat widget, a cookie banner, a feed, a video player. If a visitor taps the menu while that work is happening, the tap waits. web.dev’s advice on optimizing INP points out that script evaluation can create long tasks that delay responses to input, and that large pages take more work to render. Each embed adds a little; several embeds add up.

Lab tools can’t measure INP directly, because there’s no real visitor clicking. Lighthouse uses Total Blocking Time (TBT) instead, which measures how long the main thread was blocked during loading. A high TBT is a useful early warning for INP problems.

CLS: when embeds push your content around

CLS is the metric embeds affect most often, and the one site owners notice: you start reading, and the text jumps down because something appeared above it. web.dev lists the usual causes, including images or videos without known dimensions, third-party widgets that resize themselves after loading, and content added dynamically above existing content. Embeds can tick all three boxes.

A few details explain why some shifts count and others don’t:

1. Session windows. CLS groups shifts that happen less than one second apart into a window of up to five seconds, and reports the worst window. A feed appearing and then its images settling a moment later can land in the same window.
2. Shifts after input are excluded. Shifts within 500 milliseconds of a click, tap or key press are treated as expected. Opening something in response to a click is usually fine. Scrolling doesn’t count as input, so content that shifts while the visitor scrolls does count.
3. Position matters. Content inserted near the top of the visible area moves more of the page than content near the bottom.

The fix web.dev recommends for embeds is to reserve space: give the container a fixed size or a minimum height so the page doesn’t move when the embed arrives. Our article on where to put an Instagram feed includes a minimum-height example and explains the trade-offs, so we won’t repeat it here. The short version: reserve space, or place the embed lower on the page.

Which embeds tend to affect which metric

Every product is different, so treat this as a starting point for testing, not a verdict:

A “facade”, in web.dev’s embed guidance, is a lightweight placeholder, such as a preview image with a play button, that loads the real embed only when the visitor clicks. It trades one extra click for a much lighter initial page. Lightweight YouTube players built this way are a common example.

How Social Feed loads, and what that means for your vitals

We make Social Feed by grip space, an Instagram feed widget, so here is exactly how it loads. This comes from the widget’s code, not marketing material:

Put together: the main thing to watch with our widget is CLS from the feed appearing, and, if it sits high on the page, image loading competing with your LCP. Both have the same simple fix: place the feed below your main content. For the image side, a grid with a moderate number of posts is lighter than a slider with many; grid or slider covers that choice.

We recommend pasting the embed code exactly as provided rather than editing the script tag. It’s designed to render right where it is placed.

Measuring: field data versus lab data

There are two kinds of performance data, and small sites need to understand both:

Google’s PageSpeed Insights documentation explains that if a page doesn’t have enough field data, it falls back to data for your whole origin, and if the origin doesn’t either, no field data is shown. That’s common for small sites, and it’s nothing to worry about. It simply means lab tests and careful observation are your main tools.

Tools to use

1. PageSpeed Insights. Enter a URL to see field data at the top, when available, and a Lighthouse lab test below. Check the mobile tab first; it simulates a mid-range phone on a mobile network.
2. Search Console’s Core Web Vitals report. If your site is verified in Search Console, this report groups similar pages and shows their status from field data, for mobile and desktop. Only indexed pages with enough data appear. After a fix, you can start a 28-day validation period.
3. Chrome DevTools. Built into Chrome, it can measure Core Web Vitals for your own visits and record a page load so you can see what happened, and when.
4. Lighthouse audits for third parties. In the lab report, look for the audit about reducing the impact of third-party code, which lists each third-party provider with its transfer size and main-thread blocking time.
5. The web-vitals JavaScript library. For sites with a developer, this library measures all three metrics from real visits, so you can collect your own field data.

A before-and-after test for any embed

The most reliable way to know what an embed costs on your site is to compare the same page with and without it:

1. Pick the page where you want the embed. Run PageSpeed Insights on mobile three times and note LCP, CLS and TBT from each run. Lab results vary from run to run, so use the middle value.
2. Add the embed where you plan to keep it, publish, and run the same three tests.
3. Compare the middle values. In the report’s diagnostics, check which element was the LCP element and which elements shifted, to see whether the embed is involved.
4. If CLS rose, move the embed lower or reserve space, then test again.
5. If LCP rose and the LCP element is now an embed image, move the embed below the first screen.
6. If TBT rose sharply, check the third-party audit to see which provider is responsible.
7. A few weeks later, check field data in PageSpeed Insights or Search Console, if your site has enough traffic to show it.

With Social Feed, you can also use the widget’s Published/Unpublished switch to compare: unpublish it, test, publish it again, test. The script tag stays in place, but an unpublished widget shows nothing. See hiding your feed temporarily for how that works.

Practical fixes, roughly in order of effort

1. Move embeds below the main content. This is the single most effective change. Below the first screen, an embed can’t be the LCP element, and the content it pushes down is usually out of view.
2. Use fewer embeds per page. Ask whether each one earns its place. A page with a feed, a video, a review carousel and a chat widget pays all four costs on every visit.
3. Load embeds only where they’re useful. A chat widget or feed added site-wide through a theme setting runs on every page, including ones where nobody uses it.
4. Reserve space. Give the embed’s container a minimum height close to its final height, adjusted for phones and computers.
5. Keep post counts moderate. For feeds, fewer posts means fewer images and a smaller page. Eight or twelve posts usually show enough.
6. Use facades and lazy loading for heavy iframes. For video and map embeds, web.dev recommends loading="lazy" on iframes and click-to-load placeholders.
7. Prefer async or defer where the provider supports it. web.dev advises loading third-party scripts with async or defer unless they are needed for the first render. Follow each provider’s instructions, since some scripts, ours included, are designed to run where they are placed.
8. Audit periodically. web.dev notes that embed code changes over time. Re-test after adding new embeds or redesigning a page.

Troubleshooting common results

If the feed doesn’t appear at all during testing, that’s a different problem; see Instagram feed not showing on your website.

Frequently asked questions

Will one social feed fail my Core Web Vitals? Not necessarily. Placed below the main content with a moderate number of posts, a feed usually has a small effect. Measure your page before and after to know for sure.

Is an iframe embed better or worse than a script embed? Neither is automatically better. An iframe isolates the embed’s code but loads a whole separate page. A script that writes directly into your page avoids that, but runs on your page’s main thread. Measure the specific embed.

Does the Social Feed lightbox affect INP? Opening the lightbox is an interaction, so it counts. The work it does is small: it builds the lightbox and loads one image or video. Videos load only when the lightbox opens.

Does the free plan’s credit link affect performance? The “Powered by Social Feed” credit is a small text link with an inline logo. It doesn’t load extra files.

Why does PageSpeed Insights show different numbers from Search Console? They may show different data: a single lab run versus 28 days of field data, or one page versus a group of similar pages.

Should I chase a perfect Lighthouse score? No. The score is a lab summary. Aim for good field results, or good lab results if you have no field data, and a page that feels fast on a real phone.

Get started

If you’d like a feed that’s easy to place well, create a free Social Feed account, add the embed below your main content, and run the before-and-after test above. The setup guides for WordPress, Shopify, Wix, Squarespace, Webflow and plain HTML show where the code goes. Plans and limits are on the pricing section. Questions about performance on your site? Write to info@grip-space.co.jp.

Sources

1. web.dev, “Web Vitals”: https://web.dev/articles/vitals
2. web.dev, “Largest Contentful Paint (LCP)”: https://web.dev/articles/lcp
3. web.dev, “Interaction to Next Paint (INP)”: https://web.dev/articles/inp
4. web.dev, “Optimize Interaction to Next Paint”: https://web.dev/articles/optimize-inp
5. web.dev, “Cumulative Layout Shift (CLS)”: https://web.dev/articles/cls
6. web.dev, “Best practices for using third-party embeds”: https://web.dev/articles/embed-best-practices
7. web.dev, “Loading Third-Party JavaScript”: https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript
8. web.dev, “Browser-level image lazy loading for the web”: https://web.dev/articles/browser-level-image-lazy-loading
9. Google, “About PageSpeed Insights”: https://developers.google.com/speed/docs/insights/v5/about
10. Google Search Console Help, “Core Web Vitals report”: https://support.google.com/webmasters/answer/9205520