Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: acceleration, akamai, application, browser, cache, cdn, client, cloudflare, content, delivery, fast, http, ipv4, ipv6, network, performance, security, server, speed, web, webapp
While working on legacy apps, you might occasionally find that a developer has written a function to reload the existing page. I’ve found that in many cases, the optional javascript argument is neglected in this case and thus the ‘cached’ copy of the page is presented, often showing stale or invalid data. The solution here is simple, always specify ‘true’ to force the page to be requested from the server.
<script type="text/javascript">
window.location.reload(true);//NOTE: 'true' forces NON-cached copy to be returned
</script>
REFERENCES:
DNS is much like a phone book for the internet. For each domain name (or subdomain like ‘www’), there is an IP address that resembles a phone number. Getting the matching number for each domain can take some time and make your site appear slow, particularly on mobile connections. Fortunately, you can pre-request this information and speed up your site in most cases.
To enable a domains DNS lookup to be performed in advance of the request, you can add a single line to the <head> section of your page.
<link rel="dns-prefetch" href="//giantgeek.com" />
If you want to explicitly turn on (or off) this behavior, you can add one of the following, or their HTTP Header equivalents:
<meta http-equiv="x-dns-prefetch-control" content="on" />
<meta http-equiv="x-dns-prefetch-control" content="off" />
This is supported in all modern browsers:
- Firefox 3.5+
- Safari 5.0+
- MSIE 9.0+
If should be noted that a similar method can be used to prefetch as page, but I will save that for a different article:
<link rel="prefetch" href="http://www.skotfred.com/" />
REFERENCES:
Categories: WebStandards, Work Tags: browser, cache, dns, fetch, head, header, html, http, link, lookup, meta, pre, rel, resolution, resolve
These are useful for some advanced caching behavior, but there are cases where you might find them unnecessary for static files (in particular). Most network analysis tools will call attention to this header value, and while it seems like a trivial amount of bandwidth to send from the server to the client, the real reason for the negative score is more likely related to the behaviors that it causes in the client.
It should be noted that the default value used for the ETag is based upon the ‘inode’ of the file, as such it’s IS problematic in clustered server environments. I’ve shown the correction for this below.
Adding the following to your Apache http.conf file is a start:
# Change ETag to remove the iNode (for multi-server environments)
FileETag MTime Size
#Remove ETag from all static content, this could be done globally without the FilesMatch, but we want better control.
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset ETag
</IfModule>
</FilesMatch>
REFERENCES:
Cheers.
Categories: WebStandards, Work Tags: apache, browser, cache, caching, ETag, header, http, network, performance, server
In my testing, you don’t need to fully embrace HTML5 markup to take advantage of the “offline” functionality, you simply need to add the attribute and related files to your existing website/page. Any modern browser that supports HTML5 should automatically recognize the offline content and use it when appropriate, unfortunately no version of MSIE yet supports this.
<html manifest="/offline.appcache">
In that file, you must then specify the offline behavior, something like this is a good start:
CACHE MANIFEST
#This is to provide minimal HTML5 offline capabilities
#MIME mapping must be 'appcache=text/cache-manifest'
#Reference to this file is per page, you can have different ones in an app.
#Common image files and css may be 'cached'
CACHE:
/index.html
/css/offline.css
NETWORK:
*
FALLBACK:
/ /offline.html
On the server side, you’ll have to serve up that file with the appropriate MIME type (text/cache-manifest, for ApacheHTTPD you simply need to add one line to httpd.conf:
AddType text/cache-manifest .appcache
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: apache, appcache, application, cache, conf, html, html5, http, manifest, offline
If you make heavy (or even typical) use of your computer, you’ll often notice that it just doesn’t seem as fast as it once was. For a slight increase in performance, disk space and to generally remove some of the ‘temporary’ files/cruft that are routinely written to disk you have a few options.
Here are a few of my current favorites for doing ‘Spring Cleaning’ on my computers… BleachBit and CCleaner
Categories: Work Tags: anti, cache, clean, cruft, delete, disk, forensic, remove, security, temp, wipe
If you’ve been online at all in the last decade, you’ve heard of the “dangers” of HTTP Cookies. More nefarious and harder to remove are Flash Cookies as they are handled by a plugin/extension/addon to the browser and exist outside of the normal security settings.
To see or delete Flash data, you’ve got to visit the following URL:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html
You will probably be suprised to see many of the sites listed, as Flash is often being used to present you with ads in addition to the interactive elements that you might expect.
REFERENCES:
I spend a LOT of time trying to optimize web applications to run and appear as fast as possible, one of the most valuable tools I have in my “bag of tricks” is the YSlow! plugin for Firefox.
It integrates in the browser and gives a near real-time scoring of the pages you visit and suggestions on how to improve them. While some of the suggestions are not practical (for example: use of a CDN) the bulk of them can be applied to your application code or server with a little bit of work.
The rules and scoring mechanisms are well documented at the following website:
http://developer.yahoo.com/performance/
The YSlow! plugin is available here:
http://developer.yahoo.com/yslow/
Happy… Faster Surfing!
Categories: WebStandards, Work Tags: browser, cache, firefox, html, http, javascript, network, performance, plugin, speed, standards, yslow
This is a HUGE topic, I’ve outlined some simple steps below as well as my initial configuration for you to start with…
NOTE: this is for simple ’static’ content such as images, additional work is required for dynamic (program generated) content, such as that generated in PHP.
1. In ‘httpd.conf’ make sure the following line is uncommented.
LoadModule expires_module modules/mod_expires.so
2. In ‘httpd.conf’ add the following:
ExpiresActive On
### Expire images 1 day from when they’re accessed
ExpiresByType application/java-archive “access plus 1 day”
ExpiresByType image/gif “access plus 1 day”
ExpiresByType image/png “access plus 1 day”
ExpiresByType image/jpg “access plus 1 day”
ExpiresByType image/jpeg “access plus 1 day”
ExpiresByType image/x-icon “access plus 1 day”
ExpiresByType text/css “access plus 1 day”
ExpiresByType text/javascript “access plus 1 day”
ExpiresByType text/xml “access plus 1 day”
ExpiresByType application/xml “access plus 1 day”
ExpiresByType text/plain “access plus 1 month”
3. (Optional) Set default expiry of content in ‘httpd.conf’:
### Expire everything else 1 day from when it’s last modified
ExpiresDefault “modified plus 1 day”
NOTE: These we’re my original settings, you may want to add attitional MIME type and expiry configurations particular to your web content.
REFERENCES:
Categories: WebStandards, Work Tags: apache, browser, cache, gif, header, http, images, jpg, png, proxy, server, static
Due to my UNIX background, I’ve found it helpful, for both security and performance reasons to relocate your ‘cache’ or temporary files to a new location (Unix/Linux gurus may prefer /tmp/) here’s the simple process for doing this on a Windows machine using Firefox.
This is useful for several reasons:
* Moving many of your ‘tmp’ files/folders to a single location makes it easier to “clean house”.
* If you move ‘tmp’ to a separate drive or partition (like in UNIX), your primary drive will be less fragmented and may even show increased performance.
Firefox didn’t make this as easy to change as MSIE, but it’s a trivial matter. Find and edit the prefs.js file in your Profile directory and add the following…
user_pref(”browser.cache.disk.parent_directory”, “C:\\temp\\Mozilla”);
Alternately, you can type “about:config” in the URL/address line of the browser and add the String…
browser.cache.disk.parent_directory with a value of “C:\\temp\\Mozilla”
If you want to keep your existing cached files, you can always copy them over from the old location.
For Windows XP with MSIE6/7, the disk cache location is easily changed in the Internet Control Panel, on the General tab, Settings button. Microsoft seems to change that control panel with every new OS/browser version, but it’s generally named similarly on different configurations.
Good luck !