Fix CDN Font Delivery Problem : Nginx CORS Header & CSS

Fonts and Icon-Fonts can be easily stolen, for that reason, except Safari Browser, almost all the browsers vigorously check the control of resources. In short – web fonts loaded via @font-face or other CSS3 methods will face errors. Your Icon-Font or Font Can Be Broken if Served From CDN on HSTS Websites. Following this Guide Fix CDN Font Delivery Problem.. It is 403 server error, here is list of HTTP error codes.

Playing with only CORS Headers will not solve the problem of Icon-Fonts with this kind of appearance – [] [] [] [].You definitely know about how to create your own icon-font. By default, whenever you’ll serve the fonts & icon-fonts from CDN, the browsers will assume that you are a thief or there is security problem.

What Usually Suggested to the Fix CDN Font Problem NOT to Fix CDN Font Delivery

This common methods described by MaxCDN or KeyCDN is to use CORS with a CDN and tweak the HTTP header on your origin server. They usually talk about an HTTP header called Access-Control-Allow-Origin.

Actually we talked about this problem before in a previous article – Error and Solution for Web Fonts, HTTPS and CDN. What the CDN providers or we wrote in that article is mandatory to follow.

That is for whitelisting the Web Fonts to get delivered from CDN. But, factually there is another logical flaw which makes the icon-Fonts this wrong, unloaded appearance – [] [] [] [].

Fix CDN Font Delivery Problem : Nginx CORS Header & CSS

Best tool to check blocking is Chrome Browser’s Console (View > Developer > Javascript Console).

If you are WordPress user : WordPress W3TC has some problem with CDN rewriting. For that reason, we suggest to use WordPress CDN Linker Plugin, instead of using W3TC’s CDN tool.

Basically, if you load the CSS from your origin domain/server plus Nginx CORS Header is rightly set plus CDN’s CORS header is rightly set, no 403 error will appear. For WordPress users, you can simply do it by adding CSS as excluded file type from CDN Linker Plugin’s settings window. Flash the cache, load the webpage with Chrome Browser’s Console ON. You’ll see that no error related to font will show up. Also, if you inline CSS, that problem will not happen.

If you do not want to serve the CSS from the origin domain/server but from CDN, then you need to work a lot. In the CSS file (which is getting loaded from CDN), the font-face declaration needs the full absolute URL of the font-file :