You correct a piece of text, replace an image or update a color on your website; but when you open the page in the browser, the old version appears. The change really was made, the file on the server is new, yet it does not show up on screen. The reason is almost always the cache layers. A cache is a stored copy of content that lets the page open faster; the problem is that this copy goes stale when you make an update. Below we address the “I changed it but it still looks old” problem layer by layer.
A cache is not a bad thing; on the contrary, it is one of the fundamental ways a site opens quickly. If all files were generated and downloaded again from scratch every time each visitor opened the page, both the server load would increase and the page would slow down. That is why copies of the content are kept at various points. The problem arises because these copies are not refreshed automatically when you make an update. For this reason, the real issue is not to disable the cache entirely, but to ensure that the relevant copy is refreshed when you make a change.
Cache layers: where does the problem build up?
A web page passes through several points before it reaches the visitor, and each point can keep a copy of the content. If the change has been made but the old content keeps coming, the copy is stuck in one of these layers.
- Browser cache: Stored on the visitor’s computer. The browser keeps CSS, JavaScript and images it has previously downloaded on disk so it does not download them again.
- Server cache: A ready-made copy of the page is kept on the hosting side; the page is not regenerated on every request.
- CDN cache: A content delivery network (CDN) copies files to servers around the world. The copy closest to the visitor is served; when this copy is not updated, the old file is delivered.
- WordPress cache plugins: In WordPress, cache plugins generate a static HTML copy of pages. Even if the content changes, the plugin may continue to serve the old copy.
The special case of CSS and JavaScript files
The most misleading layer is the cache of CSS and JavaScript files. Once the browser has downloaded a file by that name, it treats the file with the same name as unchanged and does not ask the server again. Even if you change the content of the file, because the file name stays the same the browser uses the old version on disk. The result: your design change is present in the code but does not appear on screen.
The same applies to images called via url() inside CSS. If you reupload a background image with the same file name, the browser continues to display the old image because the address has not changed. This is especially misleading with large background images such as the hero section: you refresh the image, the new file sits on the server, but the visitor keeps seeing a cropped or old image.
This behavior is in fact a deliberate speed optimization. The browser assumes that a file with the same address has not changed and does not download it again; the site thus opens faster. The problem arises only when the content changes while the address stays fixed. Therefore the solution is not to disable the cache, but to be able to give the browser the message “this is now a different file” whenever the file changes.
Permanent solution: version parameter (versioning)
Clearing the cache by hand with every change is not sustainable; the real solution is to add a version parameter to the file address. Whenever the file changes, this parameter changes automatically and the browser treats it as a new file and downloads it again.
- A fixed version is not enough: With a fixed version such as style.css?ver=1.0, even if the file changes many times, because the number stays the same the browser continues to serve the old file.
- The filemtime method: The file’s last modification time is added to the version (style.css?ver=1.0.1787157120). Whenever the file changes, this value changes by itself; the browser downloads the new version, and no manual intervention is needed.
- Images inside CSS: For url() images that cannot be versioned directly, the image address is moved to a variable and the same timestamp is added to that variable; this way the image is also refreshed on every update.
Which layer do you clear, and how?
If a change is not appearing, applying the solution in layer order gives the fastest result:
- Browser: Do a hard refresh (Ctrl+F5 on Windows, Cmd+Shift+R on Mac). This makes the browser bypass the cache and fetch the files from the server again. A different device or an incognito tab is also useful for checking.
- Plugin/server: Run the “clear cache” function of the WordPress cache plugin and of the server cache, if any.
- CDN: If you use a CDN, purge the cache for the relevant files; otherwise the CDN continues to serve the old copy.
- Permanent measure: So that these steps are not needed over and over, serve the files with a version parameter.
It is worth paying attention to one point: a page that looks up to date on your screen as a developer may still be old on your visitors’ screens. Because while you frequently do a hard refresh, old copies remain in your visitors’ browsers. For this reason, to be sure that a change appears for everyone, the cache must be refreshed not only in your own browser but also at the server and CDN layers. Versioning, the permanent solution, eliminates exactly this difference: when the file changes, the address changes, and everyone receives the new version automatically.
In short, the “I changed it but it still looks old” problem is not an error but a natural consequence of caching. On a properly set up site, CSS and JavaScript files are versioned automatically; when you make a change, the visitor sees its up-to-date version at the latest on their next visit. A structure that minimizes the need for manual cleanup protects both your time and your visitor’s time.
Related services: Web Design & Software, Software & PC Applications, System Integration
Leave a Reply