I have some tabs that are ajax powered. So everytime a tab is clicked all data is loaded including javascripts. So if they click on say Tab A then click on Tab B and finally Tab A. All Tab A scripts will be loaded twice.
Now I am wondering how does the caching work. On the second time they click on Tab A how much faster will these scripts download? Or will it be as slow as the first time?
Thanks
Assuming a fairly regular load, the script will load the first time, and be pulled from the cache from then on.
Unless you're doing something tricky.
Just like you can load a huge script on the first page request of a more traditional site, and include that script of subsequent pages, but after the first page load, the browser will (typically) just pull it from cache.
Use firebug and observe the behavior.
If you are loading the same URL, the browser will use the cached version. If you want to circumvent caching, add "?" followed by a random string to the url every time u call it.
Related
I built/manage an SPA (single-page application) interface. It doesn't use modern frameworks like VueJS or React... It uses AJAX.
It's a custom interface that loads parts of the pages through ajax. When you click an item to edit, a window on page or modal is opened and all the HTML and JS dependencies of that specific page from AJAX is injected into the page. When a new page is loaded, the existing html is replaced (I do jQuery for most of the actual functionality) with like html(new_content)
Potential Problem:
Inside these ajax loaded pages, it runs javascript, for instance, "attach to this button on click", "initiates a datatables class" for the content being loaded into tables etc. When another page is loaded, it replaces the existing content from the previous, the new page loads its own JS again.
1) Unique variables loaded from the Ajax pages still exist even after a new page is loaded from ajax. (looking the variables in the console show they exist), I am assuming loading variables with the same name get replaced with new values.
2) Functions/Classes that are being added are still embedded in the memory even after I've asked it to delete everything
Another example, if I ran a setInterval() timer, after a new page is
loaded and it replaces existing content, the setInterval is still
running.
What are your thoughts here? If the user doesn't reload the actual page by using the browser refresh, then loading these ajax pages over and over again will ultimately drain the memory of the client's device?
Is there a way to keep a clean slate after each page is loaded so existing variables loaded in memory are erased? Or do I make sure each page being loaded is wrapped into an anonymous function that is cleared after each page is loaded?
I am playing around with a JavaScript code in Firebug and I would like changes to take effect in that page. Especially when there is code inside jQuery's $.ready() function.
Some kind of refreshing the page without losing of what has been edited. Is there any way to do that?
Page changes made via Firebug or via Javascript do not persist from one page load to another. Each time a page is loaded, the original HTML, CSS and JavaScript is parsed and loaded (from cache or from the server). Any prior changes will not be there.
The only way for a dynamic page change to be still present after a refresh is for you to save the changed state to a persistent location and then rebuilt the appropriate page content from that state each time the page is loaded.
But, if you make a change to the page and store some state in a cookie, in local storage or on your server, then you can have JavaScript that runs each time the page loads that gets that state from wherever you stored it and then applies the appropriate change to the page. If you're saving the state on the server (on behalf of this particular user), then you could even have the serve modify the page contents before it is served to the browser.
You can type JavaScript code in the Firebug command line and see changes take effect on the page. You can do the same in the Firefox, Chrome, Opera and Safari DevTools.
Changes to pages done via Firebug do not persist. After a page reload the original sources will be loaded again (from the server or the browser cache).
Currently Firebug doesn't allow you to edit the code of the loaded scripts directly.
Though you can execute JavaScript code within the context of the page by using the Command Line:
Or for longer scripts you can use the Command Editor:
But again, code you executed there will be gone as soon as the page is reloaded.
To make permanent changes to the JavaScript code of a page you need to have access to the server and make them there.
I would like to do something similiar to opening the developer tools in chrome and checking disable cache and then reload the page.
I can't modify the urls in any way (eg. appending a timestamp in the query) as this will work once, but next time I reload the page normally, the resources will load from the old url without the timestamp and be the old cached version.
I only need support for chrome and I don't have access to the server.
Basically I need the resource files to be update in the chrome cache, without altering the url.
referring from this topic: Prevent browser caching of jQuery AJAX call result
As you are able to editing the server-side script to setting no cache header, it is hard to handler it perfectly on IE. The only way can do for client side is unfortunately adding timestamp on end of the query string.
In Chrome reloading all page resources regardless cache can be forced by long pressing Refresh button while developer tools is open
I am creating a complete ajax application where there is one base page and any pages the user navigates to within the application are loaded via ajax into a content div on the page. On the base page I include the various scripts that are needed for every page within the application (jQuery, jQuery-UI, other custom javascript files). Then on the various pages with the application I include a script or two for each page that contains the logic needed for just that page. Each of those script files have something that executes on the page ready event. The problem is that every time the user navigates to page1, the page1.js file is loaded. So, if they visit that page 10 times, that script is then loaded ten times into their browser. Looking at the Chrome script developer tools after running around the site I see tons of duplicated scripts.
I read somewhere about checking to see if the script has already been loaded using a boolean value or storing the loaded scripts in an array. But, the problem with that is that if I see the script is already loaded and I don't load it, the page ready function doesn't get fired for the page's javascript file and everything fails.
Is there an issue having the javascript file loaded over and over when the user visit the same page multiple times?
I did notice looking at the network traffic that every time we visit the page, the script is requested with a random number parameter (/Scripts/Page1.js?_=298384892398) which causes the forced request for the script file every time. I set the cache: true settings on the jQuery ajaxSetup method and that removed the parameter from the request and thus the cached version of the javascript file was loaded instead of actually making a separate HTTP request for it. But, the problem is that I don't want all the ajax requests made to be cached as content changes all the time. Is there a way to force just javascript files to be cachced but allow all other ajax requests to be not cached.
Even when I forced caching on all requests, the javascript file still showed up multiple times in the developer tools. Maybe that isn't a big deal but it doesn't seem quite right.
Any advice on how to handle this situation?
About your first question:
Every time you load a JavaScript file, the entire content gets evaluated by the browser. It solely depends on the content if you can load and execute it multiple times in a row. I'd not consider it a best practice to do so. ;)
Still i'd recommend that you find a way to check if it was already loaded and fire the "page loaded" event manually within the already present code.
For the second question: I'd assume that the script is intended to show up multiple times when including it multiple times. To give an advice on how to not cache the loaded JS i'd need to know how you loaded the code, how you do AJAX and the general jQuery setup.
After doing some more research it looks like it is actually just a Chrome issue. When you load a script via AJAX you can include the following in your code to get it to show up in the the Chrome developer tools
//# sourceURL=some-script-name
The problem is that when you navigate away from the page, the developer tools keeps the script around, but it is actually not longer referenced by the page.
I am working with a page that contains two frames. Each frame calls a page that then calls the same javascript file in a script tag. It appears that sometimes the browser will have cached the js file by the time the other frame makes its call, thus grabbing it from the cache. But, it appears that sometimes it downloads 2 copies, one for each frame. I'm trying to figure out if it would be worth calling the script once from the parent page and have each frame's page access it that way. So is it just a matter of how fast the browser happens to download the js file, if the other frame will grab it from the cache? What's the normal protocol for the major browsers on this?
Thanks for the help!
You can have the script look to see if it has any child iframes on the page, if it does, dynamically add a script block to the child document (with the same SRC). This way the main one will ALWAYS load first and the children will always use the cache.
I wouldn't worry too much about it. If by the time the second frame needs the file it's in the cache, then it'll use the cache, if not, it'll load it too. Each browser, and each version of each browser, handles caching of files differently, so just forget about it, code each frame as a page of its own with its own includes and let the browser worry about caching them.