I am updating my site frequently after finishing updates my clients reporting that old images & scripts are getting loaded instead of new ones. I know they are coming from their browser cache but is there any way i can force scripts not to load from cache in server.
I am using nginx with php-fpm.
You can force HTTP headers to influence the browser caching behavior, however this is probably not a good idea in a production environment where you want caching.
So simply use something like:
expires -1
To force Cache-Control no-cache header
Check here for more information:
http://wiki.nginx.org/HttpHeadersModule
That being said, I have gotten myself in the habit of just changing image and static files names as I revise them. Perhaps this comes from working with CDN's where this can be incredibly helpful. So say I have static files that I might update often (i.e. they are not part of some specific piece of content). I would name them like:
someimagev1.jpg
someimagev2.jpg
somejs1.js
somejs2.js
etc.
I change values (and links in HTML source) as needed.
Related
I'm having a problem inside wordpress custom-theme, where I enqueued style, but it doesn't seem to work without linking it in the index.php , when I edit the css I have to shift+f5 to see the changes, basically clearing the browser cache. My question is if there is any way to do this automatically.
Oh and also I forgot to mention, that I'm using WinSCP for reaching the FTP server of my wordpress website.
I tried to do the auto-clear cache using php, but with many attempts it didn't do anything or even better, prevented me from manually clearing the cache.
What I'm hoping for is 2 things: 1. My enqueued styles would work without linking them in html
2. The automatic clear-cache upon updating code using php
TL;DR Use Shift-F5 liberally when developing css, and disable any caching plugins on your site when developing anything.
Shift-F5 clears your browser cache. That cache holds objects like your css files, so your users' browsers don't have to download them again as they navigate from page to page on your site, or even when they return to your site later. That means css files are sticky. Using shift-F5 while working on your css is an inherent part of web development. There's no reliable way to clear css objects automatically.
Your sample code clears the server-side caches provided by a couple of caching plugins. Avoid that. Instead disable that kind of cache while hammering out your css.
WP_CACHE prevents the use of WordPress's persistent object cache, which handles entirely different kinds of data than CSS. It needs to be defined in wp-config.php to be useful, due to the arcane way persistent object caches are implemented (via an early-loading "drop-in" module). If the words "persistent object cache" don't mean anything to you, don't do anything with WP_CACHE.
Finally, your header() calls put headers on the HTML page you're generating, not not your css, javascript, or media objects. So, they're not useful for preventing browsers from caching your css.
In a typical WordPress / php / apache web server site, WordPress never touches the content of css: the browser requests those files directly from the web server. Some caching plugins adjust the caching headers on css, javascript and media. They do that by inserting web server directives into your site's .htaccess file. Disabling those plugins during css development helps avoid caching confusion.
Your browser devtools Network tab tells you which objects the browser retrieved from cache. It's super helpful when developing with cacheable objects.
I have a very simple question, which I have been unable to find a clear answer to. I have a web page which is generated dynamically (so I absolutely do not want it cached), which loads in several thousand images. Since there are so many images, and they never change, I very definitely want the user's browser to cache these images.
I'm applying headers to the HTML page to prevent caching, by following the advice in this solution: How to control web page caching, across all browsers?
My question is: Will this cause the user's browser to also not-cache any images this page contains, or will it cache them? Thank you.
TL;DR the answer is not clear because it is complicated.
There is an ongoing struggle between a drive to do the "right" thing (i.e., follow the standards... which themselves have changed) and a drive to "improve" the standards to achieve better performances or smoother navigation experience for users. So from the application point of view you need to properly use headers such as ETag, If-Modified-Since and Expires, together with cache hinting pragmas, but the browser - or something in the middle such as a proxy - might still decide to override what would be the "clear thing to do".
On the latest Firefox, directly attached to an Apache 2.4 on virtual Ubuntu machine, I have tried with a page (test.html) referring to an image (test.jpg).
When the page is cached, server side I see a single request for the HTML and nothing for the image. What is probably happening is that the "rendering" part of Firefox does request the image (it has to!), but that is entirely supplied by the local cache. This makes sense; if the page has not changed, its content hasn't changed.
When the page is not cached, I see two requests, one for the page and one for the image, to which the server responds with a 304, but that is because I also send the image's Last-Modified header. This also makes sense - if the page has changed, the images might have changed too, so the browser has to know whether this is the case, and can only do so by asking the server (unless the Expires header is used to "assure" the client that the image will not change).
I have not yet tried with an uncached page that responds with a 304. I expect it to generate a single request (no image request to the server), for the same reasons.
What you might want to consider is that your way you will not cache the HTML page but might still perform a thousand image requests (which will yield one thousand 304's, but still). Performances on this kind of event depend on whether the requests are sent independently or back-to-back by using the Keep-Alive HTTP/1.1 extension (has to be enabled and advertised server side).
You should then use the Expires header on the images to tell the client that those resources will not go stale anytime soon.
You might perhaps also want to explore a different approach:
the HTML is cached
images are cached too
the HTML also references a (cached?) Javascript
variable content is loaded by the Javascript via AJAX. That request can be made cache-unfriendly by including a timestamp, without involving the server at all.
This way you can configure the server for caching everything everywhere, except where you make sure it can't via a single crafted request.
I develop on a remote server. I'm not sure if this is a laravel caching tendancy, but CSS and JavaScript changes tend to be delayed longer than usual. I can make instant HTML and php changes, but sometimes it takes more than a few minutes for CSS and JavaScript changes to be reflected on a page. I do know that .blade.php files are generated and cached within an app/storage/views folder, but even when I delete those the changes are not reflected right away.
I have tried on Chrome and Firefox.
Any ideas? Thanks!
CSS and Javascript are not handled by Laravel.
You can check it from the .htaccess of the public folder
Most likely you are hitting the cache browser. One solution to avoid browser cache is to append to the css or javascript a unique identifier whenever there is a new release, e.g.:
site/my/css.css?12345
^
|
+ - Change this to force a fresh copy
What ended up working best was to clear the cached views on the server, as #dynamic hinted at (Laravel and Blade store these cached files).
AS WELL, to close the tab completely and re-access the webpage fresh. There were cases where it was still cached, and so I would just switch to another browser.
I have a web application where some images are generated by PHP.
For those that are familiar, these are badges that you can put on your GitHub's projects (in the README for example).
What headers do I need to set with PHP, when generating those images (.svg), so that CloudFlare caches them for a day?
FYI I am using the free plan.
CloudFlare's documentation is very lacking IMO, I can't find anything related to static resources and TTL. To be clear: I'm not caching HTML, I'm caching static resources (that are generated by PHP).
Cloudflare respects what you put in HTTP headers. You just need to set a cache-Control: max-age value when returning your images. See this SO question.
We automatically cache .svg by file extension.
What CloudFlare caches by default
The TTL is in your performance settings for the domain.
You do need to make sure you're not returning something like no-cache for us to cache it.
Was wondering a couple of things.
Does http headers cache everything on the page. And if i have some javascript files will it cache them as well for subsequent pages, or is it more complicated then that. Example: If I cache all javascript files on page1.php will the files still be cached on page2.php or does it cache files for page1.php only apply to page1.php.
The other question is...
Should I scrap http headers and just use APC and if so how complicated is it, or in fact is it possible to use both(asking cuz yslow says to use http headers). Thanks for any info, Ive been reading but these questions weren't really answered in the text.
Your web server will take care of caching for you if you're just serving up regular .js files. The .js files will be downloaded the first time they are linked from one of your pages. When the user re-loads that page, or goes to another page entirely that uses the same .js file, the browser will used the cached copy. This applies when you load scripts via <script src="code.js"></script> tags.
That's if you have standalone, separate .js files. If, on the other hand, you JavaScript code buried in the HTML your PHP scripts generate, for example:
<script type="text/javascript">
alert("Hello world!");
</script>
...these scripts will be re-generated each time your .php file is loaded. If you're looking to cache the output of your PHP scripts then you will need to manage caching yourself by setting the appropriate HTTP headers from your PHP scripts, be that via the Cache-Control family of headers or the If-Modified-Since and ETag style of headers.
Caching and PHP files don't generally go together, though, since you're usually generating dynamic content that changes based on user input, the time of day, cookies, etc. As caching is purely an optimization the general programming warning against premature optimization applies. If you mess up your HTTP headers you can cause yourself a lot of headaches (believe me on that!). As a rule of thumb, you can probably just let Apache or IIS take care of advanced HTTP things like this and only muck around with HTTP headers if you have a specific need to do so.
I think you're confusing the different types of caching. You've talked about 3 or 4 very different things here.
browser caching -- any normal browser will cache images, JS files, and CSS files between pages. Meaning, the second time a browser wants to display any particular image from your site, it will load it from it's local disk cache instead of going back to your server for it. All this stuff just happens -- don't mess around with it, and it just works.
(exceptions: browsing user has turned off caching, you've changed headers to avoid caching, your mime.types aren't set up correctly so the browser doesn't treat these files correctly.)
server-side content caching -- if your pages are rendering slowly ON THE SERVER, you can use various disk-and-RAM caching schemes to keep the output around, and prevent the server from having to render each page each time. This only works for fairly static sites or static parts of pages.
APC content caching -- APC has commands that let you stuff arbitrary content into a server-side RAM cache. If a piece of your system takes a long time to render, but can be reused by many server hits, this is a good choice.
APC code caching -- Your text PHP scripts are "pseudo-compiled", then sent to the PHP runtime for execution. This "pseudo-compile" stage can be very slow and is redundant, so APC caches the "psuedo-compiled" PHP stage in RAM. It can speed up a whole website quite handily.
Sorry if this is TMI.