Prevent Browser Caching

FAQ

Heeft het invloed op de snelheid van de site of op SEO?

It can only help. In the recommended automatic mode browser caching keeps working at full strength — repeat visitors load CSS/JS from their cache until a file really changes, so repeat views are as fast as ever (faster than the old 2.x default, which re-downloaded assets on every visit). And the opt-in “Speed up” option goes further: one-year caching headers for your static files — the exact fix for the Lighthouse “efficient cache policy” audit. The server cost is a few file-time lookups per page — negligible. The “ver” URL parameter is the same mechanism WordPress core uses, search engines are perfectly used to it, and the plugin does not change your page content, markup or URLs seen by crawlers.

Werkt het samen met paginacache plugins?

Yes — and since 3.1.0 they can actively cooperate. Versioned asset URLs end up in the cached HTML like any others, so serving stale HTML used to mean serving old asset versions with it. When the “Also clear the page cache” checkbox on the settings page is enabled, pressing “Update versions” (toolbar, settings page, WP-CLI or an ability) also clears the detected page-cache plugin’s cache, so that HTML is regenerated with the new versions. Supported: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, WP-Optimize, Breeze, Cache Enabler, Hummingbird, SiteGround Optimizer, Swift Performance, Comet Cache. The checkbox is off by default — another plugin’s cache is only touched when you say so (for example, if your page cache serves logged-out visitors only, you may prefer not to rebuild it on every update). Either way, the report shown after every update says whether the page cache was cleared, and the version update always completes even if a purge fails. The plugin also keeps leaving HTML cache headers to the page-cache plugin.

Werkt het met page builders (Elementor, Divi, Beaver Builder…)?

Yes. Builders generate their CSS as real files (usually in the uploads folder) and give them a fresh time-based version whenever they regenerate — Elementor, for example, serves its per-page CSS as post-123.css?ver=<generation time>, and that version changes every time the file is rewritten. On top of that, in the automatic mode this plugin adds its own version component from the file’s modification time, so even a builder file rewritten in place busts its cache immediately. Together that makes the long-caching option safe for builder files too: their URLs always change when their content does.

Werkt het met minify plugins (Autoptimize, WP-Optimize)?

Yes — verified against both. Minifiers put a content hash and the source files’ modification times into their generated file names, so those files bust their own cache by name — and the long-caching option here is exactly the right policy for them: WP-Optimize’s minified CSS/JS get the one-year headers and change URL whenever a source file changes, while Autoptimize serves its cache folder with its own equivalent one-year immutable policy, so the two never fight. Files the minifier leaves untouched keep this plugin’s “ver” parameter — even when the minifier’s “remove query strings” option is on (this plugin adds its version after them on purpose).

Schoont de automatische modus mijn paginacache op wanneer een bestand wijzigt?

No — and that’s by design, not an oversight. In the automatic mode the version comes from the file’s modification time, read at the moment a page is rendered; nothing “happens” on the server when you upload a changed file, so there is no event to clear the page cache on. Cached HTML keeps the old asset versions until the page cache expires or is cleared. After bigger changes, press “Update versions” — with the “Also clear the page cache” option enabled, that both updates the versions and clears the detected page cache in one click.

Hoe los ik de Lighthouse audit “Serve static assets with an efficient cache policy” op?

Zet “Browsers statische bestanden een jaar laten bewaren” aan in het gedeelte “Versnellen” van de instellingenpagina (beschikbaar zolang CSS/JS versies aanstaan). De plugin levert statische bestanden met Cache-Control: public, max-age=31536000, immutable, precies wat de audit vraagt — en hier is dat veilig, want de plugin verandert de URL van een bestand zodra het bestand verandert, dus bezoekers blijven nooit met een verouderde kopie zitten. Na het aanzetten vertelt de instellingenpagina je of de headers op je site gecontroleerd konden worden. Dezelfde optie lost ook de oudere naam van deze aanbeveling op — “Leverage browser caching” — die GTmetrix en andere testtools nog steeds tonen.

Bewerkt de plugin mijn .htaccess?

Only if you enable the long-caching option, and only using WordPress’s own API (the same one core uses for permalinks): a clearly marked block between # BEGIN Prevent Browser Caching and # END Prevent Browser Caching. The block is updated when you change related settings, and removed completely when you turn the option off, deactivate or delete the plugin. On multisite, on nginx, or if you define the PBC_DISABLE_HTACCESS_WRITE constant, the plugin never writes the file — it shows you the rules to add manually instead.

Mijn cache plugin voegt al browsercache (expires) headers toe. Heb ik ze allebei nodig?

Nee — beheer ze op één plek. Als je cache plugin al langdurige headers voor statische bestanden levert, kun je de optie “Versnellen” hier uit laten: versies houden hoe dan ook alles actueel. Er gaat niets kapot als ze allebei aanstaan — de regels botsen niet, het laatste blok wint gewoon — maar één bron is netter. Het voordeel van ze hier beheren is dat de headers aan de versies gekoppeld zijn (URL’s veranderen zodra bestanden veranderen, dus een cache van een jaar kan nooit iemand een verouderd bestand tonen) en dat de instellingenpagina controleert of de headers echt werken op je server.

De instellingenpagina zegt dat de cache headers niet zichtbaar zijn. Wat nu?

De regels staan er wel, maar je server heeft ze niet toegepast — meestal mist de Apache van de webhost de modules mod_headers/mod_expires, of staan overschrijvingen via .htaccess uit. Vraag je webhost om ze aan te zetten, of kopieer de regels van de instellingenpagina naar de serverconfiguratie. Bij het opslaan van de instellingen wordt de controle opnieuw uitgevoerd. Zolang de headers niet werken gaat er niets kapot — browsers blijven gewoon cachen zoals ze deden.

Ik heb een bestand uitgesloten van versies — blijft het dan toch een jaar in de cache?

Als het een lokaal CSS/JS bestand is dat door je site geleverd wordt: ja. De regels voor langdurige cache werken op bestandsextensie en kunnen je uitsluitingslijst niet zien. Uitsluitingen zijn bijna altijd externe URL’s (betaalscripts, CDN’s), die de regels nooit raken — maar als je een lokaal bestand uitsluit omdat het niet lang in de cache mag, laat de optie voor langdurige cache dan uit of voeg een specifiekere regel voor dat bestand toe aan je serverconfiguratie.

Waarom krijgen externe bestanden standaard geen versie?

Several external services — payment scripts in particular (PayPal, Braintree, Authorize.net) — reject requests with an unexpected “ver” query parameter, which used to break checkout forms. Since 3.0.0 only local files are versioned by default; there is a checkbox to include external URLs again if you relied on that.

Verlies ik de browsercache met deze plugin?

Niet in de aanbevolen automatische modus. Bestanden worden normaal gecacht; de versie verandert alleen wanneer het bestand zelf verandert. De modus “bij elke paginaweergave” zet de cache van CSS/JS wel uit — gebruik die alleen tijdens actieve ontwikkeling.

De versie wordt niet elke X minuten geüpdatet zoals ik ingesteld heb. Waarom?

De verouderde modus “elke N minuten” werkt per bezoeker, met een cookie — hij bouwt niets op de server opnieuw op via cron. Elke bezoeker krijgt niet vaker dan het gekozen interval een nieuwe bestandsversie. Sinds 3.0.0 is de automatische modus in bijna alle gevallen een betere keuze.

Does it version images inside post content?

Yes, when “Images” is enabled: attachment URLs rendered by WordPress get versions immediately, and image URLs hardcoded in post content get the site-wide media version after the first update (the “Update versions” button or replacing a media file).

Mijn CDN negeert query strings.

Dan kan versiebeheer via een queryparameter de cache van die CDN voor die bestanden niet vernieuwen. Stel de CDN in om query strings in zijn cachesleutel mee te nemen, of gebruik versies op basis van de bestandsnaam (bijvoorbeeld een bestand onder een nieuwe naam vervangen).

Mijn site toont een fout nadat ik de plugin deactiveer.

Als je prevent_browser_caching( ... ) aan de functions.php van je thema hebt toegevoegd, roept die regel een functie aan die deze plugin levert. Zodra de plugin gedeactiveerd is bestaat de functie niet meer, dus stopt PHP met een fatale fout. Twee manieren om het op te lossen: stap over op de pbc_assets_version filter (aanbevolen — die veroorzaakt dit nooit), of zet de aanroep in if ( function_exists( 'prevent_browser_caching' ) ) { ... }. Zie “Voor ontwikkelaars” hierboven.