My website is developed in Wordpress and currently in production.
I've noticed .css file is cached in public_html/wp-content/cache/min/1/b1245204d8e0a4ff7cb5d1b2577fb6fa.css and every time any client request the website the same .css and others .js files generates several with random names.
Currently I'm on charge optimize WEB Core Vitals and one of the key is Performance, but I have no idea which origin files do I need to edit or modify in order when the cache re-generate those new files apply the origin changes.
It's been challenging to identify which file but not the original one.
I also use Google Dev Tool > Coverage to detect which file is affecting the performance, but it's not a good thing to modify the cached file.
Appreciate any idea or help.
Related
I have a ReactJS app hosted in S3 and using Cloudflare as DNS & CDN.
I have a huge issue, a lot of visitors have old version of the application stored in their browser cache (index.html only). I have configured advanced cache control in the newest version, but it cannot be accessed because older version is shown instead.
Static file (CSS, JS) versioning is done using create-react-app, but I have discovered that index.html file is the only cached one.
What should I do now?
How to purge visitors cache now?
PS: I have purged Cloudflare cache already and setup rule to bypass cache.
Unfortunately there is no such solution for this.
The only way is to wait until users cache will empty (expire).
It is technicaly impossible to clear users cache from external resource (JS script etc.), due to security reasons.
Also if it will be possible, there is no way how to tell users to download latest JS (including cache purging code), because they have old version of index.html (including link to those .js files).
You are stack and the only option is to wait.
A better approach would be, whenever your build changes, change the JS link so that the browser downloads the new version from the server, no matter the user's or the server's caching policy.
For example, the way Stack Exchange does it is, whenever the build changes, the HTML goes from something like:
<script src="https://cdn.sstatic.net/Js/stub.en.js?v=1bac371ac78f"></script>
to
<script src="https://cdn.sstatic.net/Js/stub.en.js?v=f83b2f654"></script>
Whenever there's a new build, you can randomize the parameter in the query string in the HTML, and still only have the single (most recent) built .js on your server.
Everytime I deploy an update to our web application customers ring in with issues where their browser hasnt picked up that index.html has changed and since the name of the .js file has changed they run into errors. Presumably because their index.html still points to the old javascript file which no longer exists.
What is the correct way to ensure that users always get the latest version when the system is updated.
We have a HTML5 + AngularJS web application. It uses WebPack to bundle the vendor and app javascript into two js files. The files contain a hashname to ensure they are different once released.
Some other information
I can never replicate this issue locally (and by that I mean in debug, on our staging site or our production site)
We use CloudFlare but purge the entire cache after release
We have a mechanism in JS that checks on page load or every 5 minutes to see if the version of our API has changed, and if so show up a "Please refresh your browser" message. Clicking this runs window.location.reload(true);
Our backend is IIS
If you need users to pick up the latest index.html when they load your site immediately after you've updated the file, make index.html non-cacheable. That will mean the browser, CloudFlare, and any intermediate proxies aren't allowed to cache it, and that one file will always be served from your canonical server.
Naturally, that has a traffic and latency impact (for you and them), but if that's really your requirement, I don't see any other option.
There are spins on this. It might not be index.html itself that isn't cacheable, you could insert another resource (a tiny JavaScript file that writes out the correct script tags) if index.html is really big and it's important to cache it, etc. But if you need the change picked up immediately, you'll need a non-cacheable resource that identifies the change.
I have a huge set of JavaScript files that need to be added to the App cache. Is it possible to add an entire folder(JS folder) in the Manifest. Else, I'll have to manually add those JS files to the manifest.
Your manifest file doesn't need to be a static file. Just write some server side code to generate a manifest based on the files in the folder.
As Maurice has pointed out, you can generate the file dynamically.
Or better still, have a background task do the work when the contents of the folder changes.
Node.js is good for this if you are already familiar with JS and have control over the server so that it can be installed. Node comes with capabilities for watching files and folders & there are a number of libraries available to make the job simple.
One key issue to watch out for though is the combined size of the files. Many browsers that support HTML5 offline use, put strict limits on the amount of data you can store offline. Typically the default limit is 5MB.
I'm using the Moxie code TinyMCE text editor (http://www.tinymce.com/) for content entry on a number of sites. At the moment I have the tiny_mce folder sitting in the folder of each site. This means that I have lots of copies of the same .js files.
I think it would be better to have one copy of the tiny_mce folder and reference it for each site - so if I make a change, or upgrade the tiny_mce I only have to do it once. Also, if I make a new site I can reference the same one to save needing to upload or copy another 9Mb of duplicated files onto the server.
I have tried putting the tiny_mce into a folder outside the individual websites and setting it up as a site on localhost that they can see.
I then include the javascript from each site like this:
<script type="text/javascript" src="http://localhost/MCE/tiny_mce/tiny_mce.js"></script>
I'm pretty sure the the file can be found by the site - I've tested with a simple javascript alert box test which works fine - and if I "View Source" and check the link it's using, I can access the tiny_mce.js file - which is the correct file.
However, the tiny_mce doesn't work.
I'm guessing there are some kind of dependencies or configurations that I'm not aware of that are causing a problem, but I'm not sure quite where to start to find out what isn't working. (I don't get any errors, it just doesn't load the tiny_mce)
Has anyone managed to get tiny_mce to share it's source files across multiple sites? Does tiny_mce require the .js files to be inside the root folder of the site in order to work?
Has anyone managed to get tiny_mce to share it's source files across
multiple sites?
I have not tried it yet.
Does tiny_mce require the .js files to be inside the root folder of
the site in order to work?
No.
Depending on your server system and in case your different website files are stored on one physical server device you could use a hardlink or softlink to the shared tiny_mce_folder (which should be accessible from the net too).
I would like user's browser to cache external .css and .js files. However, each time I made changes, I would want user's browser to be able to load the updated external files instead of using the previous cache.
I found out that by adding parameter when including ext .css and .js files will help. But when I did this, I found out that browser no longer cached the files but kept on loading the external files each time I visited the page. May I know how I can solve this?
Basically you have 2 options:
Use Etag. If you hosting provider allows it you could configure Etag in a .htaccess file:
<Directory /path/to/directory>
FileETag INode MTime Size
</Directory>
Not an parameter, add the version as a part of the filename. E.g.: style_10.css
To understand caching I recommend Mark Nottingham's caching tutorial: http://www.mnot.net/cache_docs/.
If you set the proper "Expires" headers the files will be cached even if you add dynamic URL parameters. For that is indeed the most efficient way to handle your problem.
Most web servers will use the files' modified dates to report whether files have changed to the browser. And browsers should correctly ask for files with an If-Modified header so that cached copies will be used.
Are you sure the browser isn't already doing the right thing?