I'm trying to optimize an html webpage, and one of the suggestions from yslow is:
Use cookie-free domains There are 11 components that are not
cookie-free
So I followed one of the standard solutions I've seen and created a subdomain static.mysite.com and put the images there.
But I'm still getting the exact same problem -- a cookie is still being delivered with each image, and same yslow message.
So how do I get this subdomain to be cookie free?
If you are using subdomain for cookie-free delivery then your main page has to use www prefix.
I had the same problem. The subdomain simply didn't work, so I used a different domain name and it solved the problem.
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. Yahoo! uses yimg.com, YouTube uses ytimg.com, Amazon uses images-amazon.com and so on.
Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to cache the components that are requested with cookies. On a related note, if you wonder if you should use example.org or www.example.org for your home page, consider the cookie impact. Omitting www leaves you no choice but to write cookies to *.example.org, so for performance reasons it's best to use the www subdomain and write the cookies to that subdomain.
Source - http://developer.yahoo.com/performance/rules.html
EDIT
If you set your cookies on a top-level domain (e.g. yourwebsite.com) all of your sub-domains (e.g. static.yourwebsite.com) will also include the cookies that are set. Therefore, in this case, it is required that you use a separate domain name to deliver your static content if you want to use cookie-free domains. However, if you set your cookies on a www subdomain such as www.yourwebsite.com, you can create another subdomain (e.g. static.yourwebsite.com) to host all of your static files which will no longer result in any cookies being sent.
For Wordpress you can use this config:
define("WP_CONTENT_URL", "http://static.yourwebsite.com");
define("COOKIE_DOMAIN", "www.yourwebsite.com");
Details - https://www.keycdn.com/support/how-to-use-cookie-free-domains/
EDIT 2
You will need to move your static content over to the wp-content folder of your newly created subdomain!
Related
I have managed to configure my Nginx (on top of Nodejs) to serve static files without the html extension (e.g. going to site.com/about serves the about.html page) - with help from these past questions: how to serve html files in nginx without showing the extension in this alias setup and https://serverfault.com/questions/346994/hide-html-file-extensions-using-nginx-rewrites
But I am unable to figure out how to set up Cloudflare page rules to work with this setup (the current page rules are setup to include static html files as well as js, css, etc.).
How do I configure cloudflare to serve the about.html page when the user goes to site.com/about, and also serve the team.html page when the user goes to site.com/about/team? Do I need to do anything special, or is the Nginx setup sufficient?
If CloudFlare caching of your static pages isn't required, there's no need for you do do anything, everything should work out of the box.
If you want CloudFlare to also cache those static pages, try setting up page rules to Cache Everything on your site:
Domain > Page Rules
Pattern: *site.com/*
Custom Caching > Cache everything
Once you setup the page rules, CloudFlare should cache your static pages and site.com/page1 should work. To clarify, your server is still serving the pages, not CloudFlare. With the page rules, you are simply instructing CF to cache what your server sends for site.com/page1, as opposed to fetching the page from your server for every visitor.
You can then add other Page Rules with higher priorities should you want to exclude certain endpoints from caching (e.g. an admin section). You won't need to do this if you're just hosting static HTML.
If this doesn't work, or if you need more control over what's being cached, check this CloudFlare support doc for more options.
Good luck!
I would like to write a redirect to avoid cookies being sent on graphics & css files. I think what I want is to redirect html and php to www, and others to root, possibly keeping js on the www so scripts can process cookies. This is for Joomla installations that are not cookie aware and I don't want to have to change the template files etc. Related question, can I just redirect the no-cookie files to root if the html is sent to www, or do I need to create a subdomain (which would complicate the no-change policy for the templates)
Thanks.
For reference, here's another SO question along the same lines: .htaccess, YSlow, and “Use cookie-free domains”.
As the accepted answer in that question mentions, creating a redirect from a cookie domain to non-cookie domain would be counterproductive and result in extra round-trips.
I'm not familiar with Joomla, but if as you mentioned the goal is to not mess with the Joomla templates too much, you could do one of:
Register a new domain which is an alias (cname) to your original domain. For example if you already have www.example.com, register examplestatic.com and set it to point to www.example.com. Then adjust your templates to include static files from examplestatic.com. Those requests should be cookie-free.
Use Amazon CloudFront as a CDN. You would use their Custom Origin feature to pull files from your server as the origin. Then adjust your templates to refer to the CloudFront domain instead of yours.
Going down this path may or may not provide much benefit for your situation. You didn't mention it, but I would make sure to start with the higher impact performance rules like minimizing HTTP requests by combining static files, enabling gzip compression, optimizing images, and so on.
I have a site on cakephp, developed on subdomain: dev.mysite.com. After I've redirected it to main domain(through .htaccess), sessions stoped working when I access mysite.com. Still they work fine on dev.mysite.com.
.htaccess redirect(at public_html): RewriteRule ^(.*)$ /dev/$1
Sessions are based on cookies which are (by default) tied to the current domain (dev.mysite.com in your case). If the domain changes, then the cookie (and session) is no longer accessible from a similar domain (mysite.com). What you probably want to look into is session_set_cookie_params and set the domain to .mysite.com on both sides so you can access the session information on any subdomain of mysite.com
http://us.php.net/manual/en/function.session-set-cookie-params.php
session_set_cookie_params(0, '/', '.mysite.com');
Add this before you call session_start()
Update 1:
Upon reading the the CakeSession class, it appears there's a method (and static variable) that sets the host, but it doesn't look like it's used (except in the TestCakeSession class). The alternative is to use the CookieComponent and set $this->Cookie->domain = '.myhost.com'; Then you can access the cookie from any subdomain. Note that if you use encrypted cookies, you'll have a challenging time getting the cookie values outside of the framework.
A word of caution about redirecting subdomains to main domains. If, say, you're moving a site that's a subdomain over to your main domain, that is, you're moving the files over to your main domain, then that's fine, BUT if you're closing-down a subdomain and wish to redirect users to your main domain, then you're going to have a canonical problem.
Let's say your main website is at mydomain.com, and your subdomain is at site.mydomain.com .
Then the search engines spidering any sites where you may have posted links to site.mydomain.com will treat site.mydomain.com as an additional domain to your main domain (like a parked domain), and you may even have listings to your main website having the url of your subdomain.
Frequently webmasters will DELETE a subdomain. BAD MOVE, because until the DNS changes propagate, the subdomain will redirect automatically to the main website, and the canonical issue will popup.
You need to be very careful with subdomains.
a mirroring CDN can't have the same hostname as you application server, because you need a way for the CDN to explicitly reference the application.
Why, in general, do sites like facebook run their CDN on a totally seperate host, not just a subdomain like cdn.facebook.com? example: http://profile.ak.fbcdn.net/hprofile-ak-snc4/173706_6103645_790537_q.jpg
Is the reason, that they can construct resource URLs with many different hostnames, to avoid the 4-connections-per-host limit on some browsers?
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies.
From: http://developer.yahoo.com/performance/rules.html#cookie_free
Because user generated content can contain nasties that may be able to access data hosted on the primary domain.
It also stops things like cookies and authentication getting sent in the request to CDN content.
Preventing users from inserting
scripts, and at the same time allowing
user submitted html is extremely
difficult to do on the server side -
ergo we must have sandboxing.
Borrowed from a fairly old whatwg post
A lot of big websites (facebook etc) are settings up CDN's for their content. Now I notice, that these CDN's are not always on the original domain.
Example: Facebook pictures are on "photos-a.ak.fbcdn.net"
Why is that? Is there a performance-gain in not having lots of subdomains on the "primary" domain (facebook.com)
There is quite a large performance gain for the user because with a different domain, the browser won't have to send the cookies anymore.
Read this article for more info about cookieless domains: http://code.google.com/speed/page-speed/docs/request.html#ServeFromCookielessDomain
Stackoverflow itself expains it very well on its static content site.
When the browser makes a request for a
static image and sends cookies
together with the request, the server
doesn't have any use for those
cookies. So they only create network
traffic for no good reason. You should
make sure static components are
requested with cookie-free requests.
Create a subdomain and host all your
static components there.
If your domain is www.example.org, you can host your static components on
static.example.org. However, if you've
already set cookies on the top-level
domain example.org as opposed to
www.example.org, then all the requests
to static.example.org will include
those cookies. In this case, you can
buy a whole new domain, host your
static components there, and keep this
domain cookie-free. Yahoo! uses
yimg.com, YouTube uses ytimg.com,
Amazon uses images-amazon.com and so
on.
Another benefit of hosting static components on a cookie-free domain is that some proxies might refuse to
cache the components that are
requested with cookies. On a related
note, if you wonder if you should use
example.org or www.example.org for
your home page, consider the cookie
impact. Omitting www leaves you no
choice but to write cookies to
*.example.org, so for performance reasons it's best to use the www
subdomain and write the cookies to
that subdomain.
Originally from Yahoo.
A CDN is typically spread across the world so that the user is closer to files than if all files were in the main data center.
It is difficult (impossible?) to route a single domain to different data centers.
Also, cookies no longer need to be sent. For Facebook, which has a ton of cookies due to being embedded all over the web, this can be a big saver.