Does the page load speed actually depend on third-party resources?

Does Google differentiate between its own scripts and those from others?

No. Google measures the speed perceived by the end user, without distinguishing the source of the resources. If your page loads Analytics, Tag Manager, Font API, or any Google service, those network calls are included in the overall performance calculation.

This statement settles a recurring debate: some SEOs believed that Google resources received preferential treatment. This is false. A poorly optimized Analytics script weighs as much as a Facebook widget or a third-party ad tag in the final evaluation.

How does Google actually evaluate load speed?

The engine relies on Core Web Vitals collected via the Chrome User Experience Report (CrUX). These are real-world data, coming from real users on real devices, not synthetic lab tests.

The key metrics are Largest Contentful Paint (LCP), First Input Delay (FID), or its successor Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each captures an aspect of the experience: rendering time of the main content, responsiveness to interactions, visual stability.

Why does this “overall user experience” approach change the game?

Because it nullifies any attempt to circumvent it. You cannot optimize just your HTML and ignore third-party scripts. If a tag manager spikes the JavaScript execution time, if a tracking pixel blocks rendering, if a poorly loaded Google Fonts causes a layout shift, all of this impacts your score.

Google does not consider “what comes from you” versus “what comes from elsewhere.” It looks at what the user experiences. A fast site with many well-optimized third-party scripts will outperform a slow site with few dependencies.

• No exceptions for Google resources: Analytics, Tag Manager, Fonts, Maps, everything counts.
• Core Web Vitals are measured client-side via CrUX, not in a lab.
• The origin of a resource does not influence its impact on the speed score.
• A fast and well-integrated third-party script is better than a poorly optimized local resource.
• Performance is an end-to-end responsibility: you are accountable for everything that loads on your page.

Is this statement consistent with real-world observations?

Yes, absolutely. Tests show that Google resources weigh on Web Vitals just like any other dependency. A site loading Google Analytics in an unoptimized way may see its LCP or INP degrade measurably.

PageSpeed Insights audits regularly flag gtag.js, analytics.js, or googletagmanager.com as contributors to main thread blocking time. No exceptions. Google's own tools penalize you for using... Google's tools if you do it incorrectly.

What nuances should be added to this claim?

The statement remains vague on one point: how does Google handle resources that fail to load? If a third-party CDN is down and blocks rendering, is that attributed to the site or is there tolerance for external outages? [To be verified]

Another gray area: resources loaded after user interaction. If an Analytics script only triggers after a scroll or click, its impact on LCP is null, but it can still affect INP or Total Blocking Time. The “global” in “overall user experience” remains unclear: does it stop at onload, fully loaded, or does it include the entire session?

In what cases might this rule not apply as expected?

If your site has traffic too low to appear in CrUX, Google does not have real-world data and may revert to other signals or not fully implement the ranking boost related to Web Vitals. In this case, speed still matters, but its weight in the ranking becomes uncertain.

Another edge case: pages with lots of client-side JavaScript. If most content is rendered by React or Vue after the initial load, traditional metrics do not always capture the real experience. Google introduced INP to better cover these scenarios, but blind spots remain. A SPA can display good Web Vitals on the first page and struggle during internal transitions.

What concrete steps should be taken to optimize third-party resources?

Auditing each script loaded on your pages is the first step. Use code coverage in Chrome DevTools to identify scripts that run but do nothing on certain pages. An Analytics tag on a confirmation page without a purchase funnel, for example, can be loaded deferred.

For Google resources specifically: load gtag.js or analytics.js asynchronously or with defer, use preconnect for third-party domains (<link rel="preconnect" href="https://www.googletagmanager.com">), and consider lazy-loading non-critical tags via GTM. Google Fonts should be loaded with font-display: swap to avoid blocking rendering.

What mistakes should absolutely be avoided?

Never load third-party scripts in blocking mode in the <head> without good reason. Every millisecond counts before the First Contentful Paint. If a script needs to run early, prioritize preload with as="script" instead of a synchronous call.

Another classic pitfall: multiplying third-party domains. Each new domain involves a DNS resolution, a TLS handshake, a TCP connection. If you load Analytics from google-analytics.com, fonts from fonts.googleapis.com, and maps from maps.googleapis.com, you pay the cost of three separate connections. Use resource hints (preconnect, dns-prefetch) to anticipate these connections.

How can I check if my site follows these best practices?

Run a PageSpeed Insights audit and look at the “Diagnostics” section. Identify scripts that block the main thread for more than 50 ms. Ensure that your Google resources are being loaded asynchronously and that their size is minimal (no non-minified version).

Also test with WebPageTest under 3G throttling to simulate degraded network conditions. If your LCP spikes because of a script from Analytics that takes 4 seconds to respond, you have an architectural problem. The CrUX data in Search Console gives you a real-world view: compare your mobile and desktop metrics, identify problematic pages.

• Load all third-party scripts (including Google Analytics) asynchronously or with defer
• Use preconnect for critical domains (googletagmanager.com, fonts.gstatic.com)
• Audit code coverage and remove unused scripts
• Implement font-display: swap for all Google Fonts
• Lazy-load non-critical tags via GTM or a consent manager
• Monitor real-world Web Vitals via CrUX in Search Console