A Property Site That Makes No Third-Party Requests (Fonts Included)
Open your browser's developer tools, go to the Network panel, and reload a listing page right after activating most free real estate plugins on a plain WordPress theme. You'll get a quick and unpleasant education in what "free" often means. Fonts pulling from Google's servers. A Leaflet build from cdnjs. A jQuery version hosted on someone else's CDN. The plugin didn't ask you before it started making those calls, and neither did the theme. You'll watch the waterfall chart grow as each external handshake adds its own delay before the page finishes rendering.
FW Real Estate makes zero third-party requests on a fresh install. Every font, every script, every asset the plugin needs comes from the plugin folder on your server. Nothing contacts a host you don't control. This is part of the free plugin, not something kept behind a paid add-on.
What the Network Tab Shows on a Fresh Install
Activate FW Real Estate on a plain WordPress theme, create a test listing, and open DevTools. On Chrome or Edge, press F12. On a Mac, Option+Command+I. Click the Network tab and reload a single listing page.
Look at the Domain column. Every request shows your own domain. No googleapis.com. No fonts.gstatic.com. No cdnjs.cloudflare.com. No tile server for maps. If you're on a staging environment at something like dev.yoursite.com, that domain is all you see in the list.
This is worth checking yourself rather than trusting on paper, because plenty of plugins call themselves lightweight and then pull a font from a remote server because the developer assumed no one would look. The audit here is short. The request list is clean because the assets are local, not because the plugin does nothing useful.
If you do see external requests in the panel, they're coming from your theme or from another active plugin. FW Real Estate is not the source.
The Scripts the Plugin Carries with It
The JavaScript the plugin uses ships inside fw-real-estate/assets/js/. That covers the property search filter, the listing gallery controls, and the range inputs on the search widget. Nothing is pulled from a CDN at runtime. The scripts are there whenever the plugin is active, on every environment.
There are practical benefits to this that you only notice when they stop being true. Your local development setup works the same as staging and the same as production, because the assets aren't fetched from a remote endpoint that could be blocked, rate-limited, or running a different version than your code expects. If the CDN that normally serves a popular JavaScript library has an outage, your property search still works. Version drift between what a CDN delivers and what your code assumes is simply not a failure mode you need to think about.
The FW Real Estate readme on wordpress.org documents the plugin's asset approach. Everything it lists as a dependency ships inside the plugin folder.
A CDN-hosted script can be updated, revoked, or briefly unavailable without any action on your part. A script bundled inside the plugin stays at the version it shipped with until you update the plugin itself.
Both Typefaces, Loaded from the Plugin Folder
The plugin ships two typefaces. Both live inside the plugin directory under fw-real-estate/assets/fonts/. The main plugin stylesheet points to them with a path relative to the plugin root, and the browser loads them directly from your server.
No request goes to Google Fonts, Adobe Fonts, or any font delivery network. On a listing page, the @font-face declarations in the plugin's CSS reference your own domain. You can confirm this in the Network tab by filtering for .woff or .woff2 files and checking the Domain column. Both font files should show your domain.
Why does it matter where the font comes from? A request to Google Fonts sends the visitor's IP address to Google's servers. Under Article 44 of the GDPR, transferring personal data to a third-country server requires an adequate legal safeguard. The Landgericht Munich I found in January 2022 that loading Google Fonts without consent on a German website failed that test and constituted a GDPR violation. Shipping both typefaces locally removes the transfer entirely, because there is no external server involved.
The fonts are part of the free download. No add-on required, no font subscription.
Does your current property plugin send a request to googleapis.com or fonts.gstatic.com on every listing load? The network tab tells the truth in thirty seconds, and FW Real Estate is built so the answer is no: both typefaces and all three JavaScript libraries ship inside the plugin folder, so every row in the Domain column shows your own domain. Install it and you get no Google Fonts call to add to your privacy policy, no IP-address transfer to disclose under GDPR, and no DNS-handshake delay holding back Largest Contentful Paint on every listing page. The plugin is free, and the listing pages you build with it are yours to host or move anywhere. Open the network tab after installing →
Why This Matters for GDPR and Page Speed
Two things happen when a plugin loads assets from an external server: a compliance obligation can attach, and a performance cost lands.
The consent side. Any request that carries a user identifier to a third-party server is a data transfer, and IP addresses count as personal data under the GDPR. If the receiving server sits outside the EU without an adequate transfer mechanism, you need a legal basis before the page makes that call. For a font CDN at initial page load, the practical legal basis is almost always consent, and you need it before the font renders. That means a banner, a decision from the visitor, and a degraded experience for anyone who declines. Loading fonts locally removes the data transfer, so the consent question never comes up.
The speed side. An external resource request carries its own overhead: a DNS lookup for the remote domain, a TCP connection, a TLS handshake, and then the download, all before a byte of the asset is available to the browser. For a font file, the browser can't display text in that typeface until all of that completes. This is exactly the category of latency that moves Largest Contentful Paint scores. Serving the same file from your own domain skips the first three steps entirely and reuses a connection the browser already has open.
Neither of these is an unusual edge case. GDPR audits and Core Web Vitals reports both surface third-party font requests early, because they're easy to find and the arguments for fixing them are strong on two fronts. The plugin handles both without any configuration from you.
How to Check It Yourself in Thirty Seconds
You don't need a paid audit tool. Here is the exact sequence:
- Open a listing page on your site after the plugin is active.
- Press F12 (Windows or Linux) or Option+Command+I (Mac) to open DevTools.
- Click the Network tab.
- Do a hard reload with Shift+Ctrl+R (Windows) or Shift+Cmd+R (Mac) to clear any cached state.
- Once the page finishes loading, type
googleinto the filter field and look at the request list.
If the filter returns nothing, no request went to Google's servers. Repeat with gstatic, googleapis, and cdnjs if you want to be thorough. Then clear the filter and look at the full Domain column. On a clean FW Real Estate install with a plain theme, every row in that list shows your own domain.
Run this on a listing archive page, a single listing page, and the search widget page if you're using it. All three come back clean on a fresh install.
One thing worth knowing: if your theme loads Google Fonts independently, you'll see those requests in the panel even though the plugin isn't making them. The Domain column and the Initiator column together make it easy to tell. Requests from the plugin load from paths like /wp-content/plugins/fw-real-estate/assets/. Requests from the theme come from /wp-content/themes/. Different paths, easy to separate.
When External Requests Re-enter the Picture
This is the honest part. Add an IDX feed, a map provider, or a mortgage calculator widget and external requests come back. That is not a plugin defect. It is the nature of those services.
An IDX feed pulls listing data from your MLS board's server. That is an external request by definition, and an expected one. A map widget contacts the tile provider's servers for map images. A mortgage calculator that uses live interest rates calls a rate API. None of those requests originate from the base plugin, and each one carries its own data flow to review and, where applicable, to disclose to visitors.
If you add the FW Real Estate MLS/IDX add-on at some point, the feed connection it opens is the trade-off for live MLS data, and it's the right trade-off for many sites. But it is a separate decision from what the base plugin does, made when you choose to add that service, not baked into the free install.
The baseline the plugin gives you is a property site that sends zero requests outside your domain until you choose to add a service that does. That is a cleaner starting point than most free real estate plugins offer.
FW Real Estate is a free WordPress plugin on wordpress.org. There's nothing to buy before the self-hosted fonts and libraries this post describes start working: both typefaces and all three JavaScript libraries are in the free download, and a clean install confirms it with the network check above.
Paid add-ons, each delivered as its own WordPress plugin after purchase, extend the base with features that bring external connections by design. The MLS/IDX import add-on covers RESO Web API providers, CREA DDF, and the UK and European portal feeds. Board and provider feed fees are your cost, billed directly in your name. The agents, maps, favourites, and the rest of the add-on range are available separately once the free plugin is running.
The demo at realestatewordpress.fastw3b.com runs the full add-on range, so it shows more than the free plugin installs on its own.
