You can find meaning of code busting at https://www.keycdn.com/support/what-is-cache-busting
The main point is that when new version is deployed, uses should use new feature with avoiding cache feature.
My app is deployed with Universal SSR and using scss.
I checked deployed files and css codes was included at html so css is not related to cache busting.
Also, I checked js file and whenever the js file is builed, the filename seems changed with some random string. I think it support cache busting on js file.
My conclusion is that nuxt support cache busting. Am I right? If then, Can you give proper reference on nuxt website or webpack configuration codes on github??
Thank you!
Related
I am currently working on a Nuxt + Express project which is deployed to AWS. The application is in SSR mode as it is required for the application to render on the server, however, the requirement is to cache the client assets (dist/client) in S3 bucket for each build so when a page /page/{id} is reached, it will show a version in which it was built in, even if the version of the application changed. We will cache these for several months.
The problem for me is that when the application is built, the assets are generated in the dist/client, but for the Nuxt's SSR mode, these headers are dynamically added in the dist/server, therefore I am unable to cache them.
Is there any way to have these headers on a client-side using SSR mode?
Hanging around this problem from quite a few days..
I have an angular 5 application, I am using some js files which are present in src/assets/js/*.js of my angular app's project directory. Since to achieve good performance, i am using lazy loading technique for loading of these js files.
I have a script.service.ts file in the app folder which loads the js files, i provide the names of the js files to this service to make it load. I also have a script.store.ts file where i have mapping of the js file names with there paths. Script.service.ts uses this path to load the js file with the mentioned name.
Problem - Now, whenever i change something in my js file and deploy the application, the changes are not getting reflected in the browser since the files are already cached. I have used gulp plugin to append a hash content to these file names with task runner, but i cannot make changes in the code of script.store.ts every time, since the content hash is unique for each file..
I am searching for a solution where i can achieve cache busting having incorporated this lazy loading feature of js files..
I hope i will get the solution soon. Thanks in Advance.
Currently using Wakanda 1.1.3 with a mostly Angular4 on client side, yet, a few prototype pages persist from
our initial project. Provided we make the necessary file structure, module, login and syntax changes for v2,
will Wakanda v2.4+ serve our older prototype pages?
If so, is there anything special or unique that we need to do to get a prototype page to load?
You can save the WAF files (JS & CSS) generated by the v1.1.3 runtime for each prototype page.
Open your prototype page in a browser.
Open the browser console.
Save both waf~css and waf~js files.
Hard link these files in your prototype page.
This should be enough to run on Wakanda v.2.6.0
I am making a website in Codeigniter and not using any client side framework like angularJS. However I need some features of angularJS like downloading the JS and CSS once at the client rather than downloading it for each page. As my website content is much dependent on the server, should I use angularJS? I read that it makes tha application slower.
your question is not about angular at all!
I recommend you to read something about build systems like require, grunt, yeoman...
What you want to do is ajaxifying your website, as Stever said it's not about angular at all..
you may use RequireJS to load the script when a page need it.
For a best perfomance, use grunt for running any task like : minifying, compressing your stylesheet and so on..
I am creating a mobile singlepage web app using jquery mobile. The webapp includes a number of javascript files and a number of css files. I have written a deploy script that concatenates and minifies js and css files, and now I am wondering whether I should inline the concatenated js and css directly in the HTML file - please note that I am talking about a singlepage app here (I know that this would be a bad idea in a traditional web 1.0 app with dynamically generated HTML). I am also using appcache/manifest file to cache the singlepage app so that subsequent access to the web app will be served from the cache, so it is the initial load time that is my primary concern.
When I inline everything (jquery, jquery mobile etc.), my 7kb HTML file increases to 350kb (100kb zipped) but now everything can be loaded in a single request.
But am I missing some other benefits such as parallel downloading of js files - and would it therefore be better to not inline the css and js, but instead just concatenate all js and css to a single js file and a single css file and then fetch each of them in separate requests?
Are there any limits regarding file size that I should be aware of? Maybe caching in network routers works better with smaller file sizes or whatever?
So my question boils down to whether it is a good idea to inline everything when making singlepage mobile web apps?
The answer to how much should be concatenated and how much should be inlined varies depending on a number of conditions. The final answer is you should do A/B testing and find what works best for you. From what you describe I recommend you definitely NOT inline 350K of CSS & JS. If you do this then any change to the HTML or JS or CSS requires downloading the entire payload. Instead, compartmentalize those changes and forced updates by keeping HTML, JS, & CSS as separate requests. You could do dynamic | inlining to make the first response fast but leverage (app or localStorage) cache for subsequent requests, but that's going to get complicated when coupled with app cache (because the HTML doc is saved to app cache). Otherwise, just keep them separate, save each resource to app cache, and update individual resources as needed.
I would not recommend inlining everything into the html if your webapp could be accessed from different urls with different querystring.
Example :
http://webapp.com/?fb_token=fdsf
http://webapp.com/?referer=bla
http://webapp.com/?tracker=toto
Each of those will add a master copy in the appcache (you can veryfy it by looking at chrome://appcache-internals/ in chrome). You then risk to reach the quota limit for appcache in term of cache. Furthermore on appcache update, the browser goes through its appcache entry list and ask a fresh copy of it.
A good compromise that i am following for mobile device & appcache , is to keep the html tiny and then have one big css (containing base 64 inlined images) and one js file.
FYI, there is currently a quota limit on the size on the sum of all your listed resources in appcache in the order from 5MB to 25MB (25 being the new iOS6 limit)
-seb