What does a WordPress plugin load from third-party servers?

The question

Which WordPress plugins load something from third-party servers on a plain page view?

This is the question agencies have to answer for their clients, and it is usually answered with guesses. No measurement existed.

The method

One dedicated WordPress Playground in the browser per plugin. The plugin is installed from the directory and activated; nothing else is configured. Then, logged out, the home page and a post are opened, the way a visitor would. Every network request is recorded and grouped by host.

Four decisions are what make the result hold up, plus the sample.

Subtract the baseline

First a run with no plugin at all. Result: zero third-party hosts. WordPress with its bundled theme fetches nothing from outside on its own. Everything that shows up after that was installed by someone.

What counts is the frame a request comes from

Only what comes out of the WordPress frame is counted. Requests from the Playground shell are measurement environment. Why a blocklist of hosts is useless for this is shown below in the false alarms.

Measure logged out, and only start counting after the logout

The question is about a page view, so: front end, not signed in. The cut-off from which requests are counted sits behind the logout. Why that matters is shown by the second false alarm.

Configure nothing

What is measured is the state straight after activation. That is reproducible and it is the state most installations stay in.

This limit belongs in every sentence about the result. A plugin that only fetches data once an account is connected sits at zero here for good reason, and it would be wrong to conclude that it never fetches anything. The statement is: out of the box it fetches nothing.

The sample

All 67 plugins with at least one million installations from the Plugin Directory Census 01/2026, plus our own six. That makes the selection defined rather than picked: anyone above one million installations is in.

One plugin dropped out: litespeed-cache. The Playground failed to come up in four attempts, in neither of the two modes. That leaves 72 measured.

Our own plugins sit in the same table as everyone else. They are six of the 72 slugs: hafen-core, hafenstudios-ads, heckgalerie, linkjet, wellenbrecher, wimpel.

The self-test: why a zero is worth anything at all

A quiet result only says something if the instrument can prove that it moves. The self-test uses a mu-plugin to hang a known third-party request into the front end:

$img = '<img src="https://example.com/hs-selbsttest.png" width="1" height="1" alt="" />';
add_action( 'wp_footer', function () { echo $img; } );

Measured on 16 September 2026, with no plugin at all. Our measuring tool speaks German, so this is its output as it came, with the English reading next to it:

Grundlinie messen (ohne Plugin) ...
  1 fremde Gastgeber ohne Plugin: example.com

measuring the baseline (no plugin) ...
  1 third-party host without a plugin: example.com

So the chain holds: home page loaded, logged out, frame filter permeable, request captured. A zero in the table is a real zero.

Two false alarms, both of our own making

Both are here because a measurement without its failed attempts cannot be checked.

Elementor and Google Analytics

The first run reported a hit on region1.google-analytics.com for elementor. The address gives itself away:

dl=https%3A%2F%2Fplayground.wordpress.net%2F%3Fmode%3Dseamless
dt=WordPress%20Playground
en=error&ep.source=bootSiteClient

That was the analytics of playground.wordpress.net reporting a boot error of its own. A blocklist entry for google-analytics.com would have been the wrong way out: a plugin that really does load analytics into the front end is exactly the finding we are after. Since then the frame a request comes from is what decides. After that, elementor sits at zero.

wps-hide-login and Gravatar

The second run reported a hit on secure.gravatar.com for wps-hide-login. The frame in the log:

https://playground.wordpress.net/scope:happy-quiet-valley/wp-login.php?action=logout

That was the admin bar on the logout page, so WordPress core on a page no visitor ever sees. The counting cut-off sat before the logout instead of after it. After the fix: zero.

Result, front end

Of 72 measured plugins exactly one loads something from a third-party server on a plain page view: hostinger-reach loads js/embed.js from cdn-reach.hostinger.com, twice, on the home page.

That finding was measured twice independently, on 15 and 16 September 2026, in both runs with the home page as the frame and logged out.

All 72 measured plugins in the front end, logged out, straight after activation. Sorted by number of requests, then alphabetically.

The question assumes that many plugins phone home on a page view. Measured, they do not, as long as they are not configured. Site Kit with no Google account connected loads nothing. Instagram Feed with no account loads nothing.

The risk arrives with the setup. Installation alone does not create it. Anyone reviewing data protection therefore looks at the configured plugins, one by one.

Result, dashboard

Of 72 measured plugins, nine load something from third-party servers as soon as the operator opens their own dashboard. Every finding was measured twice independently, on 16 September 2026, and both runs agree.

The baseline in the dashboard is above zero: when signed in, WordPress loads secure.gravatar.com by itself for the avatar in the admin bar. That is subtracted and counts for no plugin.

The nine dashboard findings, with where they occur and what kind of request it is.

google-analytics-for-wordpress (MonsterInsights) and optinmonster are the two cases in which the operator themselves is sent away, before anything is configured. MonsterInsights lands on connect.monsterinsights.com, and the address carries along: site_url=…, rest_url=…/wp-json/monsterinsights/v1, onboarding_key=…, return_url=…. OptinMonster lands on app.optinmonster.com/wp-welcome, and the address carries along: connectionToken=…, wpUrl=…. Both plugins come from the same house.

On top of that, OptinMonster loads Adobe Fonts on its page (use.typekit.net, eight requests) and a tracking pixel p.typekit.net/p.gif that sends along the host name of the website (h=…).

Five of the nine cases are fonts from Google Fonts. wp-smushit loads its fonts from fonts.bunny.net, and it happens on the WordPress plugin list.

All 72 measured plugins in the dashboard, signed in, straight after activation. The WordPress baseline is subtracted. Sorted by number of requests, then alphabetically.

What the measurement does not say

• Nothing about the configured state. Connect an account and the numbers change.
• Nothing about requests made by the server instead of the browser. A plugin that calls a third-party API server-side does not show up here. That is worth a measurement of its own.
• Nothing about the contents of the requests. What was measured is that something is fetched, and from whom.

Raw data for checking the numbers

For each plugin and each run there is a JSON file. It records the host, the number of requests, the request type, the full addresses and the frame the request came from. Alongside that sit the baseline with no plugin and the list of measured slugs.

Both tables on this page are generated from exactly those files, row by row. The column “Requests” is the sum of requests across all third-party hosts of a plugin.

The instrument is a script of our own (fremdanfragen.mjs) that drives the WordPress Playground and evaluates the network log. If you want the files to check the numbers, write to moin@hafenstudios.com.

Measured by

Measured on 15 and 16 September 2026 by hafenstudios, Hamburg.

Corrections and objections to moin@hafenstudios.com. A documented correction will be added to this page.