I created a domain on CloudFlare, a website with HTML and CSS, hosted my bucket with those files on S3, and integrated terraform for deployments. When I kick off terraform apply and run the aws cli command to update the S3 bucket, formatting changes like text show immediately but my CSS changes like font sizes and colors take several hours to be visible. How can I make both types of changes visible quickly?
I tried hard reloading my browser, clearing cache, and setting auto minify on cloudflare. I haven't tried gzipping my css and min.css files, a little afraid I might break something. I'm unfamiliar with front end development. Suggestions?
For a proxied ("orange clouded") DNS record, Cloudflare applies a default caching behaviour. This includes default cached file extensions such as CSS files. The default behaviour, caching and extensions cached are documented here.
When you do a release on your origin (S3 bucket), you could purge the cache so that the old cached versions are discarded and new ones will be pulled and cached. You can also override the cache behaviour by using Page Rules. By the way, Page Rules (and other Cloudflare settings) are also manageable via Terraform.
Related
I've been using S3 to host static websites and I've made changes to the HTML & CSS files and have seen those changes reflected in the past. For some reason I go to do the exact same thing I've done before, change the style of one of my sites, and no change would take place. In-fact after deleting all previous files, the old build was still rendering. I had no version control on that particular bucket.
Content-type is set to 'text/css'. My file structure is normal with index.html being in the root. My normal steps of creating or updating new or existing sites has not changed, but S3 has for some reason.
When I click on the index.html file and go to the public url link, it reflects all my changes.
My only fix is to add the full url to the style link.
<link href="https://s3.amazonaws.com/{bucket-name}/css/style.css">
Does anyone know why this is happening or how to fix it other than adding the http link? If not, I hope my solution helps others for this weird S3 issue. Normally you can just upload your files to a bucket, set the policy and finally enable hosting after stating the root html file.
It might be due to your browser caching, where it's loading locally stored assets (CSS stylesheet) from a previous time you've visited the URL rather than fetching the new resources in an attempt to speed up load times. There are settings you can change in your browser to determine how long your browser will hold onto cached resources before fetching new ones.
By setting the stylesheet link directly to the s3 bucket URL, it will cause it to fetch the new stylesheet every time the page is loaded, which leads me to believe that caching is the issue here.
Try clearing your cache and see if it solves the problem.
Here is a deeper explanation of the concept with respect to browsers, and a list of commands to perform a cache refresh depending on what browser/OS you have!
I think it's the CSS folder's doesn't allow you to access the files inside. If you make the folder public, it will work.
Select all your files and folders, go to actions tab and then select make public to allow objects to access one another.
While tuning my web app, I noticed that certain of my images are never loading from cache, even though they're completely static:
This particular file always loads from the server, but it should be cached. The only thing somewhat special about the file, AFAICT, is that it's sourced via a CSS class, which specifies the file via a background-image style. I'm not specifying any tricky headers or anything; it's just a regular jpg file.
There's a lot online about preventing caching, but I can't find anything about making it work when it doesn't seem to be.
Do you have caching software on your web server? If yes is it enabled? Since some can be disabled such as UnixyVarnish what is mainly found in cPanel. Images do get cached by default. Regardless of how its displayed. And your browser should automatically cache websites you visit, unless you have disabled it.
I'm running a Rails 3.2 app on Heroku. For about a week we were serving assets via CloudFront by setting config.action_controller.asset_host to our CloudFront URL in our config/production.rb file. This was working successfully.
This past weekend, however, I noticed that after a deploy to production our website looked very off, and the reason was that it was serving stale CSS. I looked at the css file it was serving (using inspect element in Chrome), and the CSS was an md5-hashed application.css file coming from CloudFront. I removed the asset_host line (so that assets would be served directly from our app) and deployed again (without changing any css), and noticed that the site, which now looked fine, was serving application.css with a different md5 hash.
So it appears that for some reason, CloudFront was serving an old version of application.css, and I'm guessing this is because our application was telling users' browsers to serve an old version of application.css.
To add one more variable: we do cache the home page and part of our our layouts/application.html.erb file (which contains the stylesheet tag), but on each deploy we clear the cache via Rails.cache.clear.
So my best guess is that Rails.cache.clear might not be properly invalidating the cache. We use the dalli memcache client, if that helps.
Any insights or suggestions would be greatly appreciated!
Update:
I tried moving the CSS out of the cached block and re-enabling CloudFront, but the CSS still appears broken. So it doesn't appear to be related to caching the header.
Update 2:
It looks like this is a CloudFront issue, because when I inspect element and change the CSS URL in the to our root domain (instead of the CDN domain), the CSS renders correctly.
Since a md5-hash collision is extremely unlikely, it seems like CloudFront is serving the wrong CSS file when I'm requesting the correct md5-fingerprinted CSS file. Any ideas?
assets are not automatically synced to your CDN when you deploy an app on heroku. In the deployment script on heroku it does do the rake assets:precompile task but it does not then place them into your CDN. You'll have to create some sort of mechanism to do this on your own on deployment of your app.
Somebody else asked a similar question and you might want to have a look at what the suggestions were there: Rails 3 automatic asset deployment to Amazon CloudFront?
I have change a bit of code in my CSS from Magento for my header logo but Magento doesn't load my new CSS update and still shows the old one.
I have already refresh the cache in Magento
Flush Magento Cache
Flush Cache storage
Flush Javascript/CSS Cache
At System - Cache Management
I have a folder var/cache and in here folders like mage--0, mage--1
i have tried to back-up them so i can restore it when i delete them and something won't wrong but i cant back-up it.
Hello first of all you can always safely delete the contents of var/cache you do not need to back it up. I konw it might sound silly but did you clear browser cache? Also make shure you changed the correct css file, use Firebug to see if your changes are not overwritten by other rules. A link to the project and more information will be helpful.
It may be that the browser is caching your files, not the server. To check, try either merging your files or unmerging your files and refresh the page. If you see the changes, then it is indeed your browser that is caching the files.
In that case, we've developed a handy little extension that automatically refreshes the merged JS + CSS static files. http://extensions.activo.com/css-and-javascript-versioning.html
you may be using different theme. check in system config design section what package and theme you are using and then check for that folder in skin and change. delete the var cache and changes will show. you do not need to back up var cache
Its also important to check System -> Design, where design overrides are located. Recently we've had a problem with this, someone (we are not sure who, hacker?) added override without dates, and whole shop become broken (we have pretty sophisticated package with lots of modifications). It took us about 30 minutes to figure out what was going on.
I wanted to know that, is there some special requirement for a website to make use of CDN ?
i mean is there some special scheme(or atleast considerations) on which your website must be build right from the start to make use of CDN (Content delivery network).
is there anything that can stop a website from making use of CDN, for example the way it references the content files, static file paths or any other thing conceivable.
Thanks
It depends.
You have two kinds of CDN services:
Services like AWS Cloudfront that require you to upload the files in some special place that they read from (eg. AWS S3) - In this case you need have a step in your build process to correctly upload the files and handle the addresses somehow inside your application
Services like Akamai that just need you to change and tweak your DNS records so they will serve the request to your users instead of you - In this case you would have two domains (image.you.com and image2.you.com) and have the image.you.com pointing to Akamai and image2.you.com pointing to the original source of the file. Whenever a user requested an image in Akamai, they would come to you through the "back door", fetch it and starting serving that file always.
If you use the second approach it's really simple to have a CDN supporting your application.
There are a whole bunch of concerns when dealing with CDN solutions.
The first one is that a CDN can't serve a dynamic page - i.e. a page that is unique to every user. Typically, that includes PHP, ASPX, JSP, RubyOnRails etc. - so if you're hoping to support lots of users for a dynamic site, you have to come up with another solution. Some CDN providers support "Edge Side Includes" - this allows you to glue dynamic pages together with cached content on the CDN, but this creates quite a complex application.
Of course, even on a dynamic application, a CDN can still serve static files - images, stylesheets, javascript files, videos etc.
#Tucaz explains the two major options here (actually, Akamai also provides a "filestore" CDN option). If you select the second option - effectively, the CDN becomes a caching reverse proxy in front of your website - it makes sense to tweak the cache headers on your HTTP server, and tell the CDN to honour those. Make sure you set your .ASPX files to not cache!