{"id":61837,"date":"2021-08-25T12:31:19","date_gmt":"2021-08-25T17:31:19","guid":{"rendered":"https:\/\/blog.cpanel.com\/?p=61837"},"modified":"2021-08-25T12:31:19","modified_gmt":"2021-08-25T17:31:19","slug":"how-to-use-cookie-free-domains-for-faster-website-performance","status":"publish","type":"post","link":"https:\/\/devel.www.cpanel.net\/blog\/general-knowledge\/how-to-use-cookie-free-domains-for-faster-website-performance\/","title":{"rendered":"How To Use Cookie-Free Domains for Faster Website Performance"},"content":{"rendered":"\n
Cookies are how websites remember. Without them, they forget you as soon as a page finishes loading. This ability to remember allows you to log in to a content management system or put products in an ecommerce shopping cart. It\u2019s what allows a dynamic CMS like WordPress to personalize web pages. But sites don\u2019t need to include a cookie with every file they serve, and needless cookies increase latency and generate unnecessary network traffic. <\/p>\n\n\n\n
Cookie-free domains let you separate content that needs a cookie from content that doesn\u2019t, ensuring that your site only serves cookies when it needs to. In this article, we explain how to set up and use a cookie-free domain. We use WordPress as an example, but a similar process works with other content management systems and ecommerce stores.<\/p>\n\n\n\n
An HTTP cookie is a small piece of data a site sends to a web browser when it first loads a page. The cookie contains a unique identifier the browser stores alongside other information about the site. When the browser loads another page, it sends the identifier with the HTTP request. In this way, the site knows when a series of requests come from the same browser.<\/p>\n\n\n\n
When logging in to a website, you authenticate with a username and password. If you enter the right credentials, the site sets a cookie so you don\u2019t have to re-enter your credentials every time you load a page. This process is called session management; a series of otherwise independent requests are linked to a session by the cookie.<\/p>\n\n\n\n
This ability to remember is used in other ways too. The site can send personalized content unique to each visitor; an ecommerce store can, for example, display your recent orders because the cookie links an HTTP request to order data associated with your account in the site\u2019s database. In a more controversial application, advertisers use cookies to track you; they set a cookie, and advertising code across the web uses it to build a profile of the products you might be interested in.<\/p>\n\n\n\n
The web needs cookies, but that doesn\u2019t mean every HTTP request does. For example, when you open a page with embedded images, each one triggers an HTTP request. But images don\u2019t change depending on who loads them, so serving a cookie is a waste of bandwidth. You may want to load different images for different users, but that\u2019s handled in the web page\u2019s HTML. The page needs a cookie; the images don\u2019t.<\/p>\n\n\n\n
The same is true of other static assets such as JavaScript code and CSS. A page might load dozens or even hundreds of static assets, all with useless cookies attached. The time and bandwidth consumed by unnecessary cookies soon add up.<\/p>\n\n\n\n
Removing cookies from static assets might seem straightforward, but cookies are controlled at the domain level. You can\u2019t serve assets with and without cookies from the same domain. Instead, you need a cookie-free domain just for static assets.<\/p>\n\n\n\n
There is one more domain-related wrinkle to consider when setting up a cookie-free domain. Subdomains inherit cookie settings from their top-level domain. If you set cookies for \u201cexample.com,\u201d they are also served on \u201cwww.example.com\u201d and \u201cblog.example.com,\u201d and so on. So, you can\u2019t host your dynamic content at \u201cexample.com\u201d and your static content at \u201cstatic.example.com.\u201d<\/p>\n\n\n\n
There are two ways around this:<\/p>\n\n\n\n
In our walk-through of setting up a cookie-free domain, we assume you host your site at a \u201cwww\u201d subdomain and intend to host static files at a \u201cstatic\u201d subdomain.<\/p>\n\n\n\n
With cPanel & WHM, creating a cookie-free domain for WordPress is straightforward.<\/p>\n\n\n\n
Open cPanel and navigate to the Subdomains<\/em> tool, which you\u2019ll find in the Domains<\/em> section of the main page.<\/p>\n\n\n\n Create a new subdomain of the top-level domain connected to your WordPress site. If your WordPress site is hosted at www.example.com, create a subdomain at \u201cstatic.example.com\u201d or similar.<\/p>\n\n\n\n In the Document Root<\/em> field, enter your WordPress site\u2019s \u201cwp-content\u201d directory. In this case, the site is hosted in \u201cpublic_html\u201d so we enter \u201cpublic_html\/wp-content.\u201d<\/p>\n\n\n\n