It’s easy for front-end designers and server-side engineers to create web sites that don’t play well when SSL and Content Delivery Networks (CDNs) are added to the site.
Fortunately it’s also easy to solve that by understanding how to design HTML and site structure in advance to support those.
One of the most helpful things that can be done is to have well-defined URLs for HTML, images, CSS and JavaScript in the following scenarios:
- homepage content rooted under /, like ., images, css and js respectively
- admin site content rooted under /app, like ., images, css and js
- CDNs where you may store content in the future, such as a network-local proxy, Amazon, Akamai or Limelight. Generally a remote URL is overlaid onto the homepage or admin site structures listed above.
If you have localized content, each of the subdirectories above may be subdivided by ISO language code also.
Generally HTML and URLs intended for web browsers and email clients needs to be considered separately:
- web browsers handle relative URLs well
- email clients do not handle relative URLs as well as browsers, if at all. For example, not using an absolute URL or not specifying the scheme (ie. //domain.com) will cause problems in most email clients.
- in both cases, HTTP servers can use URL rewriting if necessary to make changes after the design is done.
Relative URLs not only help with HTTP to HTTPS transitions, but also in creating developer sandboxes, and test and QA servers.
Try to make as many links as possible relative in your HTML as possible if you’re planning on using SSL or test servers in the future. Fixing the links later can be expensive as it requires testing the entire site again for broken links.
By having reserved directory paths for images, css and html, it’s possible to set far-future expiry times to improve cacheability of those assets. However, the filename may not be reused, so new version of images need to receive a new filename or else caches will continue serving the old content.
And by having a URL available for items that could be served from a CDN, it’s possible to configure your CMS to be CDN-aware from Day One and avoid site changes and testing later. One of the first things I check when evaluating CMS programs these days is how I would easily be able to change serving images from a local web server to a remote CDN.
