Just about all web users understand how links work: after clicking a link, your browser magically transports you somewhere else, either on the same site or a completely different one.
For browsing the web, that understanding might suffice, but if you need to build and maintain your wpPERFORM site, there are a few additional tricks that might come in handy: protocol relative URL’s and root relative URL’s.
First, let’s explore a URL, or uniform resource locator, a little more closely.
The image above highlights the 5 major elements to the URL for this post. Those elements are:
- The protocol, which is the secure HTTPS
- Some punctuation, where is the standard ://
- The domain or hostname, which on this site is wpperform
- A Top Level Domain, or TLD
- A path or slug
Another term, Universal Resource Identifier or URI, sometimes gets included in this discussion, but in most cases it’s not a helpful addition so we’re going to ignore it here and stick to the term of URL.
After the protocol and the punctuation, a URL includes a domain or hostname, which isn’t case sensitive, followed by a path, which on most servers is case sensitive. In WordPress terms, the path is often referred to as the slug. The Slug metabox for this post from the WordPress post editor is shown nearby.
Protocol Relative URL’s for Internal Links
If your site’s future might include doing e-commerce or taking payments, protocol relative URL’s can offer a benefit when it’s time to add that functionality. Protocol relative URL’s make the most sense when you’ll use a single protocol over your entire site.
Protocol relative URL’s use the protocol of the current page to open links on that page. If the current page uses the insecure HTTP, and on that page you include a link with a protocol relative URL, your browser will open that link using the same insecure HTTP protocol. But if you later secure that page, that same link will open using the secure HTTPS – without requiring you to update the link or incur the small time cost of the redirect.
To do e-commerce or take payments, you’ll need to use the secure HTTPS protocol on one or more pages. Sometimes, it’s simpler to secure the entire site. In this situation, we’d do a 301 redirect from all insecure (HTTP) URL’s to their new secure (HTTPS) locations to avoid creating duplicate content. That redirect adds a very small amount of time to loading the secure page. Our tests when composing this post showed a 15 to 25 ms period to handle the redirect. While that’s a very, very small time penalty, it can be completely eliminated using protocol relative URL’s.
For external links or in those cases where you might not opt to use the same protocol on your entire site, protocol relative URL’s have to be used with caution. For example, if you use a protocol relative link on your secure page to an external site that does not support the secure HTTPS, you’ll trigger a browser warning similar to one shown below from Firefox when attempting to reach that external link.
The warning is triggered because the protocol relative link will attempt to open using the same secure protocol of your site, but the URL you’re attempting to reach only supports the insecure HTTP. For external links, in most cases, an absolute URL using a protocol that works is the best choice.
Root Relative URL’s
Root relative URL’s omit the first 4 elements of a full URL, including only the path. In effect, the first 4 elements establish the root of the site, and a root relative URL takes those as a starting point to reach the resource at the specified path. The unlinked root relative URL to this post is /relative-urls/
Root relative URL’s are a huge help to developers who might build a site in 1 environment before making it live on its own domain or who maintain 2 copies of content, 1 on a live site and a second copy on a development site.
A development environment and a live environment will each have their own roots. When a site is moved from a development environment to a live environment, root relative URL’s don’t have to be updated. In contrast, every absolute or protocol relative URL has to be updated when moving from a development to a live site. Admittedly, this can be done using scripts to automate the process, but it’s an extra step and runs the risk that something breaks.
Root relative URL’s have a major drawback: they don’t work when the URL is separated from the root. For example, root relative URL’s can’t be shared, and they can confuse web crawlers because the root is missing. For this reason, outside of serving a specific need during development, we don’t recommend using root relative URL’s.
Document Relative URL’s
There’s still another type of relative URL, a document relative URL. Document relative URL’s don’t offer much functionality for a typical WordPress site, but we’ll briefly cover them for the sake of completeness.
While root relative URL’s start with a forward slash, document relative URL’s begin with either ../ or the first character of the slug. For a website built on a structure of folders, document relative URL’s provide a way to more easily link to resources within this folder structure. Adobe has a good discussion of document relative URL’s, because its HTML editor Dreamweaver is often used on sites with a folder structure. However, few WordPress sites use such a folder structure, so document relative URL’s don’t offer a big advantage over root relative URL’s in WordPress in most situations.
One exception to the limited role of document relative URL’s are URL’s in a theme’s stylesheet, where the theme makes use of folders, such as a folder for images. For example, when used in a stylesheet, the document relative URL images/logo.png refers to the file logo.png in the images folder where the stylesheet is located. Note that it’s missing the leading forward slash that would make it a root relative URL. The document relative URL eliminates the need to worry about where the stylesheet is located, as long as the images folder is located in the same place.
Root relative and document relative URL’s are necessarily protocol relative. Since no protocol is specified in these relative URL formats, the URL’s will load the resources using the protocol on the root or document.
Some URL Examples
Here are a few specific examples of relative URL’s:
In summary, relative URL’s can offer valuable flexibility when adding links to your site, especially if you plan to add secure content in the future or use both development and live environments for the same site.
While relative URL’s are sometimes useful, they can’t be used in every situation and shouldn’t be used without understanding their limitations. Absolute URL’s are always the safe choice. For example, as we discussed in setting up Google Analytics Demographics and Interest Reports, Yoast’s Google Analytics for WordPress plugin offers an option to specify a host for ga.js, but the resource specified must be an absolute URL, not a relative one.
Simple links might never seem the same with the knowledge of all that goes into a URL.