From WikiFur, the furry encyclopedia.
Jump to: navigation, search

This page is a personal article, and may not conform to WikiFur's standards for tone or neutral writing. As a courtesy, please contact the author, GreenReaper, if you wish to make major changes.

Furry fandom lives online, and much of its time is spent on fandom-specific websites. Unfortunately, most have not been designed with performance or efficiency in mind. I would like this to change.

If you have the power to address the issues mentioned here, or have similar issues on your own website, please consider resolving them. It really isn't that hard, and your users will thank you for it. Large sites might also consider the effect that saving on bandwidth will have on your hosting costs or CPU usage.

General advice[edit]

  • Read the tutorials and guidelines linked at the bottom of this page. Follow them where possible.
    • If you want to break the rules, then do so. But at least a) know that you're doing so, and b) understand why it's OK in that particular situation. For example, ETags can be discouraged because they take up header space and usually aren't useful if you have multiple servers. But if you only have one server, they're probably better than downloading the whole image again.
  • Use the tools linked at the bottom of this page. Fix the problems they highlight (there will be problems).
    • Surf to a different portion of your site and use them again. If you have forums or subsites, try there.
  • If users are downloading something that is not already compressed, tell your server to use GZip to compress it when serving it to the browser, shortening the download time.
    • This applies especially to HTML (static or dynamic via PHP/Perl/etc), JS, CSS, XML, RSS and ICO files. The page itself is required to display anything, so time saved is immediately noticeable.
    • If you're using Apache, you'd normally do something like this in your config:
      LoadModule deflate_module /usr/lib/apache2/modules/ [adjust path appropriately for your server; may not be necessary if already loaded]
      AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript application/javascript
    • If you're using IIS, enable "static" and "dynamic compression" under HTTP Compression on the Service tab of the website properties
    • If you use PHP and don't have access to the server configuration, try adding <?php ob_start("ob_gzhandler"); ?> to the top of your scripts instead.
    • With ASP.NET in the same situation, use Global.asax
    • If you're using a forum or gallery application, check to see if it has a GZip option. Consider using a lighterweight style for them, too.
    • Remember to test that it is working afterwards.
  • If users have to download the same static content or site images/JS/CSS twice, you're probably doing it wrong. Cache-control max-age is there for a reason; use it to tell the browser what images are not going to change, so it doesn't have to guess.
    • An Apache cache directive matching all files in a directory (and subdirectories):
<Directory /a/b/c/w/skins>
  ExpiresActive On
  ExpiresDefault A34560000
  • A directive matching all files with a particular extension:
<FilesMatch \.(jpg|png|gif)$>
  ExpiresActive On
  ExpiresDefault A34560000
  • A directive matching all files in a particular web location:
<LocationMatch ^/favicon\.(ico|png)$>
  ExpiresActive On
  ExpiresDefault A34560000
  • If you need to update the file later, just change the name. You can add a number to it with a redirect or a query parameter (e.g. file.css?123) to achieve this.
  • Users are not developers. Optimize for their browser's needs. Minify your JS/CSS, and remove comments from JS/CSS/HTML unless absolutely necessary for them (you can always run in a special mode for yourself).
  • Arrange your HTML so the content comes first. If you have a lot of webcounter buttons higher up, guess what loads first? Not good if you're trying to load a comic.
  • The fewer requests, the better. Try not to have ten JS or CSS files where one would do. If you have lots of them, bundle them together. You can do the same for images with a CSS sprite. There may be some tension here with giving people stuff they might not use - measure it!
  • If you do have to make lots of requests, spread them across multiple subdomains to encourage browsers to download more files at once. Remember, you can make a new subdomain point to the same directory.
    • If you have large cookies, place these images on a domain or subdomain that does not have cookies so they are not uploaded in the request for the images.
  • If you're telling the user's browser to resize images to make thumbnails, you're doing it wrong. Do it yourself and serve a smaller thumbnail, then cache it (and tell browser to) so you don't need to generate or send it again.
  • If you're using common JavaScript libraries like Prototype, consider loading them from Google instead of serving them yourself.
  • Put JavaScript at the bottom of a page unless you really need it up top.
  • Use opportunities to prefetch JS/CSS/images. This isn't that useful for most sites, but you may find situations where you can do so - for example, if you have a front page and an image or JS/CSS file on [a page/pages] that most people subsequently go to.
  • Validation will only get you so far. A page can be perfectly valid and still perform terribly.
    • Consider the more relaxed standard of HTML 5 rather than XHTML (which has recently been discontinued). <!doctype html> is shorter, speeding your pages - and it lets you eliminate <html> and <head> if they are empty, and provides defaults for the types of Javascript and CSS files. See the source of for an example.
  • Measure the results! If you're not seeing the improvement you hoped for, double-check your assumptions and make changes.
  • Check the file size of thumbnails and user icons. Is it reasonable? 100x100 thumbs should probably be 5-10kb, 200x200 below 25kb. JPG is almost always the right choice, though PNG can be suitable in some circumstances. Either way, ensure you're getting a good level of compression. There are some really sub-optimal PNG converters out there, and with JPG you have to pick a good quality level.

Back-end performance[edit]

These tips are oriented towards front-end performance, but remember that back-end performance can be just as important too.

  • Most sites could benefit from caching of (at least) static content with a reverse-proxy/web accelerator like Squid (used by WikiFur and VCL) or Varnish, or a secondary webserver like nginx (used by Fur Affinity) or lighttpd. Shield "heavy" servers like Apache and Mongrel from these requests or you will chew up CPU cycles to no good use.
    • If you have dynamic content and you want to cache too, you will have to send a purge message (perhaps using HTCP) when the content has been updated. It's a little more complex, but it can make your site really fast. MediaWiki, for example, supports this if properly setup.
  • If you're using PHP, you should be using APC or something similar to cache opcodes (and preferably user data too)
    • Even if you can't cache everything when a user is logged in, consider whether you can cache parts of the page or data. Anything that requires effort to regenerate is a potential target, even if it's user-specific (use user-specific keys).
  • Check your database queries for performance (and security) issues. If you don't know how, find someone who does.

Site-specific tips[edit]

Here's where I give specific advice. These may be otherwise excellent sites - indeed, if they weren't popular enough for me to notice they wouldn't be here. This criticism is based solely on the ways in which the performance of the site may be improved for users.

The first two or three suggestions are likely to make the most impact. They're often the easiest to implement, too - adding GZip or setting a cache-control directive should be a five-minute change. Things like buying and using a separate domain for static images may be unnecessary and/or impractical for all but the largest sites.

I've concentrated on the situation where the site is not in cache. That's because a) this happens more often than you'd think, and b) these are the users for which performance has the biggest factor in whether or not they continue to use the site. But cached performance is important, too, and you should try to put all possible content in the cache. After all, regulars may use the site less if it's slow.

If you fix something on this list, feel free to <s>cross it off</s>[edit]

  • Enable GZip compression for site CSS and JS
  • Site images should have a far-future cache expiry date set
  • The site JS and CSS should be minified as well as being concatenated. Use the newer Google Analytics JS which is minified already.
  • The banner should be a PNG rather than a GIF
  • Misc forum images could be combined into a CSS sprite
    • Unlikely due to forum images coming from a variety of Drupal modules


  • Enable GZip compression for site HTML (and CSS/JS, if it gets any)
  • Set far-future cache-control expiry headers on JPG and GIF files, or at least on the following directories: /ads/, /cvnm/, /fmz2/, /lgos/, /navv/, /site/gfx/ and /img/uploads/pics/.
  • Use text with style if possible rather than graphics as textual headers and links.
  • Convert the many graphical elements into one or a few CSS sprites.
  • Convert the main logo to PNG format.


  • Files in the /images/ on the assets subdomain should have a far-future expiry cache-control headers set
  • The other images and JS should be marked as cacheable. You have a timestamp in there already, it'll download another if that changes.
  • Site JS is in a large number of files, it should be combined and minified.
  • External CSS should come before external JS to ensure it can be downloaded in parallel
  • Cut tags from the CSS where not needed. For example, if a class is only used on body, then specifying body#class is redundant.
  • Move images and site CSS/JS to a completely separate domain that doesn't have any cookies, perhaps with subdomains to speed parallel downloads.


  • Enable GZip compression for site HTML, CSS and JS (includes heart., forums. and
  • Add a far-future expiry cache-control header for the subdirectories and files:
    • /images/ and /comic/ (on main and heart.)
    • /js/ (on main)
    • and /images/
    • /base.css and (put a version number in the filename if changed)
    • and /favicon.ico on all sites
  • Recompress the following files with a tool like optipng or pngcrush:
    • All PNG-based comics (significant savings; also use "reduce color depth if possible" option to convert to 256-color mode)
    • at least bg_fence2.png, bg_comicnav.png, bg_footer.png, bg_comic.png, bg_night.png and links/flist.png in /images/ on the main site
    • (as a 256-color PNG)
  • Minify/js/jquery.easing.1.3.js and /js/scripts.js, and cache if possible
  • Consider reducing the number of images used in layout, or combining them into imagemaps and/or CSS sprites, or if nothing else serving them from a separate virtual subdomain
  • Consider switching to the new Analytics ga.js file rather than urchin.js


  • Enable GZip compression for site HTML and CSS
  • Add a far-future expiry cache-control header for the subdirectories of /frontpage/ and /forum/templates/fiplain/
  • Consider whether some of the CSS files can be combined and minified, particularly those in /frontpage/rsc/css/

Cub Central[edit]

  • Enable GZip compression for site HTML (including PL output), CSS and JS
  • Add a far-future expiry cache-control header for CSS files in /web/, and for the favicon
  • Consider whether some of the CSS files can be combined and minified


  • Enable GZip compression for site HTML (including dynamic pages like /wiki), CSS and JS
  • Add a far-future expiry cache-control header for the /javascripts/ folder, and consider increasing the timeouts on the /images/, /stylesheets/ and /data/ directories and subdirectories (and the favicon), as well as changing their caching option to "public".
  • Minify /javascripts/application.js
  • Recompress /images/spash.png and /images/wordmark.png, and convert the other images to PNG format.
  • Specify width, height for the image files on the front page.
  • Consider serving images from a separate cookie-less domain
  • Check the performance of the custom CSS - it's probably not necessary to specify both a tag and a class, only specify the class. Descendant selectors can also be expensive, avoid them where possible.


  • CSS, JS and common site images (including favicon) should have far-future expiry cache-control headers
  • Site JS and CSS should be minified
  • Switch to using the newer Analytics JS that is minified
  • The thumbnails inconsistent in file size, and some are (arguably) too high a quality
  • Multiple forum icons could be converted to a CSS sprite


  • Enable GZip compression for site HTML, CSS (there's no JS).
  • Add a far-future expiry cache-control header for files in subdirectories of the /themes/ and /modules/ directories (particularly CSS and image files used by the site).
  • Convert /themes/Flayrah/images/flayrahlogo.gif to PNG format.
  • Remove the broken link to button.png.


  • Enable GZip compression for site HTML, CSS and JS
  • Add a far-future expiry cache-control header for files in the /LINKS/ and /SHARED/ directories, as well as /styles.css, and subdirectories of the directory
  • Convert the GIF images in the above directories to PNG.
  • Minify
  • Consider adding a separate subdomain or domain to access the above images from.

Fur Affinity[edit]

Fur Affinity has gained something of a reputation for being slow when it's up, and down more often than that. This is a little unfair in 2009, though, as it's pretty stable and speedy now. Still . . .

  • Avatar images appear to be 100x100 but resized to 50x50. This may make it faster to load if you ever need to see the full-sized ones, but that's rare (especially for those on the front page), and it makes them four times larger than they need to be.
  • The avatar images are in GIF; PNG should be considerably more efficient for those which are not animated.
  • The non-custom story and poetry thumbnails should be static images rather than copies of the same image under different names.
  • /js/script.js and js/quick-replyto.js could be minified unless debugging is needed by that user (and possibly combined). There are also many inline blocks that should be externalized or merged if possible.
  • Images could be served from multiple different virtual subdomains, preferably all on a completely new domain that has no login cookies. This applies to both site and content images.
  • BBCode images could be combined into one CSS sprite, saving a bunch of requests.
  • Many of the CSS rules are inefficient because of their length (it has to check them from the right and it can take a long time to figure out which ones don't match). Use more IDs. If there is only one type of tag with a class, you don't need to qualify it with a tag name like div#whatever.
  • Cache-Control:Public might be suitable for images on a, d and the banner.
  • Use protocol-relative URLs for avatars, images and the like. You're already on http:, so you don't need to include that in the URL - start with the //
  • The FA forum has several GIF images that could be better as PNG, including the header, logo, footer image and dark backgrounds. All could do with being served from a cookieless domain.
  • The forum also has an Infobar stylesheet that should be linked in the head, not the body, and the head contains a large CSS chunk that should be in an external file.[edit]

  • Enable GZip compression for HTML (including PHP), CSS, and JS
  • Add a far-future expiry cache-control header for /images/ and favicon.ico, and and favicon.ico
  • Minify wikibits.js (after you've updated from MediaWiki 1.11.0)
  • Switch to using the newer Google Analytics JavaScript file that is minfied
  • Serve static images from a separate domain without cookies


  • Enable Gzip compression for HTML (including PL), CSS and JS.
  • The CSS should be moved from the HTML to an external CSS file linked in the head
  • Scaling fullsized images to make thumbnails is a bad idea. Make separate thumbnails for display on the front page.
  • Auction images and uploads should have a far-future cache-control expiry time
  • Use relative URLs. If you're on, /cgi-bin/auction/ is the same as


  • Enable Gzip compression for HTML (including SHTML) and CSS.
  • The JPG thumbnail creator seems to be set on a very high-quality mode. An 80x62 thumbnail should not be 45kb. Let it compress them.
  • Site images and thumbnails do not have a far-future cache-control expiry header set
  • Serving the images from a separate cookieless domain might help, though not much as the cookies are quite small. As a bonus, use subdomains of that domain for more downloads on older browsers.
  • There are several raw JS blocks in the HTML that should probably be externalized and called as functions.


  • Enable GZip compression for HTML (including PHP), CSS and JS, on all sites (main, digo store, forums, . . .)
  • Set a far-future cache-expiry time on files in the directories /images/, /optim/ and /secondary/images/, /online/, and the favicon, as well as any other directories with static images in, like
  • Minify the JavaScript block inside the front page. Optionally, extract it into a separate file, minify that, and cache it separately from the HTML.
  • Load the front page graphics in CSS sprites to avoid making 70 requests to the server for separate graphics. It takes at least 2.5 seconds to download all of these and much of the delay is queueing (would also be faster once you GZip the HTML, since it would find out about the images faster).
  • Load images from multiple virtual subdomains to get around connection limits. (These images could probably be served faster using a reverse-proxy like Squid, too, and would take the heat off Apache)
  • On the forums, minify and (where appropriate) combine all scripts in the /jscripts/ folders, /cache/lang_cache/en/lang_javascript.js and /style_images/blue/folder_js_skin/ips_menu_html.js, and set cache-control headers on those and the subdirectories of /style_images/.
  • Convert all static GIF files to PNG sitewide on all sites, except where they come out larger (only likely for very small images).
  • Avoid browser scaling of images such as Instead, resize it, convert to PNG and use that directly.[edit]

  • Enable GZip compression for HTML (and CSS and JS if it were used)
  • Set a far-future expiry cache-control header on the /2009/graphics/ directory (and any other graphics directories)
  • Use PNG or JPG rather than GIF for graphics
  • Try to avoid splitting up into so many different graphics. Split up a larger image using CSS sprite techniques if necessary.
  • Use text and font styling rather than graphical buttons with text on them


  • Enable GZip compression for HTML, CSS and JS.
  • Set a far-future expiry cache-control header on the /img/ directory (and subdirectories), /main.css and /favicon.ico
  • Consider switching to the new minified ga.js rather than urchin.js
  • Recompress /img/newshit.png and /img/badkarmaempire.png with a PNG optimizer, convert /img/banners/button_stumbler.gif and /img/banners/button_y100.gif to PNG
  • There is no </head> tag. Use <!doctype html5> if you want to do that (then you can take out <html> and <head> as well :-).


  • Specify a far-future expiry cache-control header for all site images, thumbnails and content. New content should have a new filename.
  • Minify /ajaxtabs/ajaxtabs.js, /style_images/furnationd/folder_js_skin/ips_menu_html.js and /cache/lang_cache/en/lang_javascript.js
  • Combine the /jscripts/ JS and perhaps ajaxtabs.js into one file and minify that instead
  • Crush PNG files in images/Buttons/ and convert GIFs in /images/ and /ajaxtabs/ to PNG
  • If you're on you don't need to give an absolute href like - just use /folder/file.x
  • Serve static images and content from a separate, cookieless domain[edit]

  • Specify a far-future expiry and public cache-control header for all files in /themes/ and /thumbs/, the favicon.ico, and ideally the files (consider adding a last-modified date to the filename to allow them to be cacheable and also replaceable).
  • Don't make the browser scale avatar images. Make smaller thumbnails yourself and serve them instead when a smaller image is required.
  • Consider converting the many site theme images to CSS sprites
  • Consider serving static site images from a separate domain, or at least another subdomain.
  • Move the link to /tmp/blue_biglib.js before the inline JavaScript, if possible.
  • Remove redundant protocol (http:) and host name ( from friendlinks, remove redundant protocol from userav img src links.[edit]

  • Enable GZip compression for HTML, CSS, and JS. This is really critical for this site because it has long pages and specifies that they cannot be cached.
  • Specify a far-future expiry cache-control header for all static items, such as the subdirectories of /templates/, /img/ and /avatars/, the pligg CSS/JS and the site banner and favicon.
  • Minfiy (and gzip) /js/xmlhttp.php.
  • If you know the size of the banner image, specify it so that it does not cause the page to resize.
  • Use the newer Google Analytics JavaScript which is minified rather than Urchin.
  • Serve static site/template images from a different virtual subdomain, or ideally from a completely different domain which has no cookies

Furry to Furry[edit]

  • Enable GZip compression for CSS and JS.
  • Specify a far-future expiry cache-control header for subdirectories of /furry/images/ and /furry/clientscript/ (the latter is currently not cacheable at all).
  • Consider more aggressive compression of /furry/images/styles/spring/misc/right.jpg (and does the blank 1/3 of that need to be there?).
  • See if you can combine the four script files loaded from /furry/clientscript/ into one.
  • Serve static site/template images from a different virtual subdomain, or ideally from a completely different domain which has no cookies.
  • Using the entry page to prefetch CSS, JS and images used by the site itself.


  • Enable GZip compression for HTML, CSS and JS, including the forums.
  • Specify a far-future expiry cache-control header for the subdirectories /includes/, /skins/adobe/images/, /tinymce/jscripts/tiny_mce/, /smf/Themes/default/images/ and /DB/Ads_files/
  • Consider using indexed PNG rather than GIF for forum theme images, and JPG for ads.
  • Investigate combining some of the many Javascript files that appear to be plugins into one.


  • Specify a far-future expiry cache-control header for all static CSS, JS and images in all subdirectories of /design/, /file/ and /plugins/ (consider a shorter one for the user avatars too) and for favicon.ico.
  • There are currently 11 JavaScript files being downloaded - try to combine them. The same for CSS if possible.
  • Enable GZip compression for CSS and JS.
  • Minify the JavaScript and CSS files, especially the large library downloads accessed via index.php?f=....&t=js and the ones in /design/.
  • Consider recompressing the following files: /design/pic/signup_button.jpg, /file/style/KWA/bottom.jpg, /design/pic/login_button.jpg, /file/style/KWA/topbar.jpg, and everything in the /file/pic/bookmarks/ directory.
  • Use the newer Google Analytics JavaScript which is minified rather than Urchin.
  • Access static files from a virtual subdomain, or better, on a completely new domain which does not have cookies.
  • Try to put the inline JavaScript at the end of the <head> section rather than interleaved with other linked files.
  • Link to /design/kwaimg/style.css in the <head>, not the <body>.


  • Enable GZip compression for HTML, CSS and JS.
  • Specify a far-future expiry and public cache-control header for /images/ and /javascripts/ (using Vary: Accept-Encoding on the latter, as well as query version numbers if refreshes prove to be required)
  • Combine the files in /javascripts/ together into one file and minify it.
  • Remove the div from div#topNav rules in base.css, and the div from div.homepage div.introBox and other div.homepage rules in index.css
  • Make images in * safe to cache by adding a date or version to their names. Then actually add appropriate far-future expires cache tags.
  • Serving images from separate subdomains for each user means separate DNS lookups for each user. It would probably be better to serve them all from a single domain (or small number of domains) for static images.
  • Recompress the files /images/64-blank-userpic-[01].png using a PNG crushing tool. The main logo could also be slightly smaller.
  • Remove the empty script section from the end of the <head>
  • You can remove the "http:" from links to other http: sites (like when you're already on http:. DB[edit]

  • Enable GZip compression for HTML, CSS and JS. This applies to as well.
  • Specify a far-future expiry and public cache-control header for images in /lib/tpl/default/images/ and for /yappy-fursuit.gif (which should be a PNG, and should be actually resized to 347x320 rather than having the browser resize it), as well as subdirectories of and that site's JS and CSS.
  • Remove from all URLs on the same site - a link to can be rewritten /a.jpg (may need changes in dokuwiki itself since it generates these links).
  • Consider multiple subdomains for images of to increase the speed of downloads.


  • Enable GZip compression for HTML, CSS and JS.
  • Set a far-future expiry and public cache-control header in subdirectories of /assets/ and /av/, and the favicon
  • Convert twitter and RSS feed GIF images to PNG
  • Is that huge 144kb PNG background really needed? Consider just loading the edges.
  • Consider a separate virtual subdomain or domain to host static content[edit]

  • Enable GZip compression for HTML, CSS, and JS. This applies also to the forums.
  • Site images in /fc2010/images should have a far-future expiry cache control header added
  • /fc2010/javascripts/wz_tooltip.js, /fc2010/javascripts/functions.js and forums/lib.js should be minified
  • Site images should ideally be in a CSS sprite, especially since they're much the same colour - they'd compress better.
  • "./X" is (as far as I know) not necessary to designate a URL relative to the current location. Just use "X".
  • The forum images could be crushed to be slightly smaller.


  • Enable GZip compression for HTML, CSS, and JS (applies to the forums as well)
  • The /img/ directory and site CSS should have a far-future expiry cache-control header date set. Ideally, so should content. The same applies to the forums' /Themes/Furtopia/images/ directory and its subdirectories.
  • Several front-page images ( Wicca.jpg, head-left.jpg, head-right-02.jpg and head-back.jpg ) could do with more aggressive compression.
  • should be minified, and the larger files in /Themes/Furtopia/images/ could be more heavily compressed.
  • There are several identical images in /artwork/img/ and /artwork/ - use one consistently on the artwork page to avoid multiple downloads of the same file.
  • Place the stylesheet <link>s before the inline Javascript in the forum pages so it can be downloaded in parallel.[edit]

  • The front page logo could be compressed to be a lot smaller (possibly even more if reduced in colour depth). It should also be marked as cacheable.
  • Everything else should be marked as cacheable, including all site images and probably all content images.
  • Gzip and minify site CSS and JS in and respectively.
  • Parenthesize access to by making multiple virtual subdomains (t1, t2 etc.) and assigning images to each one based on their ID.
  • Serve thumbnails and other static content -from a completely separate non-cookie'd domain
  • Switch to using the new Analytics js that is minified
  • Use some of the savings from the above to reduce the number of ads, which slow down everything else. :-)


  • Enable GZip compression for HTML (including PHP output), CSS and JS. This applies to the forums too.
  • Set a far-future expiry public cache-control expiry header for the contents of /images/, /styles/ and their subdirectories, and the same for /images/, /files/ and /templates/ subdirectories on the forums
  • Increase the thumbnailer's compression level. A 113x150px thumbnail should not be 55kb.
  • Extract the embedded subTrail CSS from the forums and place it in a linked CSS file.
  • Convert the text button images to simple text with styling. Consider doing the same for some forum images, or make a CSS sprite for smaller images.
  • Consider loading images/CSS/JS from a separate subdomain, or a separate domain without cookies. This applies to the forums too.


  • Enable GZip compression for HTML, CSS and JS.
  • Set far-future expiry cache-control headers on everything within the /assets/ directory and subdirectories, and the favicon.
  • Minify and combine (if possible) the various JavaScript asset files used
  • Try to use CSS and real text rather than an image for the introductory text and other titles.
  • Optimize the banners/header logo images - those PNGs could be smaller.
  • Avoid the use of browser-scaled thumbnails. Make another thumbnail at the appropriate size and cache that instead.
  • Use a different domain with no cookies to serve images, JS/CSS and other static content.[edit]

  • Enable GZip compression for HTML, CSS and JS.
  • Set far-future expiry cache-control headers for the aforementioned CSS and JS, and for the /personals/images/ and /pictures/ directories - the latter two should also have the public cache-control option.
  • Minify /js/overlib.js
  • Increase the compression level on the thumbnailing algorithm. A 68x50px image should not be 35kb.
  • Resize images /pictures/header-hyena.jpg, /pictures/create_acct_s.png, /pictures/login_s.png and /pictures/help.gif to their display sizes; do not specify their width and let the browser resize them
  • Add a virtual domain for static site images/CSS/JS and thumbnails, or a completely separate one with no cookies.[edit]

  • Enable GZip compression for HTML (including PHP), CSS and JS.
  • Set far-future expiry cache-control headers for the /images/ directory, /art/ and /gallery/ and their subdirectories, the site css and js files and the /favicon.ico and /gallery/images/favicon.ico. Remove the non-cacheabiliity from /images/dark.gif.
  • Convert GIF files in /images/ to PNG.
  • Combine all CSS files into one.
  • Create separate subdomains to load gallery images and site style in parallel with other downloads. Consider a completely separate domain for images/CSS/JS so they don't get cookie requests.
  • Consider making a single CSS sprite out of the site images.


One of the oldest furry art sites still around. It's got a pretty simple layout, and it uses Squid to serve images quickly, but there's still some easy things that could be done to make it a faster site.

  • Enable GZip compression for HTML, CSS, and JS (though it doesn't use much of the latter :-).
  • None of the site images or content images have a cache-control header, which could bandwidth for repeat visitors, though it does at least use ETags. If content files could be updated, add a timestamp to image URLs so that they will change.
  • The site uses GIF for site images; converting to PNG could deliver a small saving.
  • The wiki HTML, JS and CSS should be gzipped
  • The forum HTML should be gzipped, and the images under /vclforum/images-logos/ and /vclforum/images-vcl/ should have a long-term cache expiry date set. Ideally the style of the forum should be converted to CSS, externalized and minified as well
  • Using multiple dedicated subdomain names for serving images might speed downloads on gallery pages.


Since the author runs this website, it should do pretty well, right? Well, mostly. Unfortunately it takes a lot just to get MediaWiki to "pretty good", and there are still a few areas to improve (this applies to the domain)

  • Many external JS and CSS requests are made, some for small or empty files
  • The flag images on the main page should be combined into a CSS sprite
  • CSS, JS and images (at least pooled images) should be served from a separate, cookieeless domain.
  • The Ajax JS should be put at the bottom


  • Enable Gzip compression for CSS and JS, which should affect //, /templates/Golden_Glades/Golden_Glades.css, /templates/FI_Apple/fiapple2.css, // and //
  • Enable Gzip compression for HTML (including PHP) output in //
  • Add far-future expiry cache-control headers for the /images/ and /templates/ directories and subdirectories, and perhaps some caching on the files in //
  • Content-Style-Type is not really needed as it is assumed to be text/css. The language attribute on JavaScript files is definitely not needed.
  • /images/wolfbbs_link.jpg could probably be more-heavily compressed without significant loss in quality, given the size
  • If possible, serve static images and CSS/JS from a separate domain which users do not have cookies for to eliminate them from client image requests


  • None of the site images, javascript, CSS or content have explicit cache expiry times set, though ETags are present. (This includes forum images in and /Smileys/classic/)
  • 12 JavaScript files are used on the front page alone. These files should be combined and minified (especially considering most are standard libraries).
  • There's a whole bunch of javascript embedded in pages that should be split to separate files or combined with the above.
  • Converting site images to PNG (or using pngcrunch) could decrease their size, particularly:
    • /layouts/helsing1/images/main_inside.png
    • /layouts/helsing1/images/backgroundfade8.jpg
    • Everything in /images/ and its subdirectories
  • The site layout uses a large number of images, compounding the cost of not having a cache expiry set; combining these into a single CSS sprite could be beneficial.
  • Using multiple dedicated subdomain names for serving images might speed downloads on gallery pages.

Yiffy International[edit]

  • Enable GZip compression for HTML, CSS, and JS, including on and any other sites
  • Set a far-future cache-control expiry header on the contents and subdirectories of /image/, /skins/, /includes/, //, // and //, as well as favicon.ico on each site.
  • Recompress the PNG files in the /skins/blue/ folder with pngcrush or a similar tool.
  • Minify the scripts in /includes/ and its subdirectories, and in
  • Move the lightbox javascript link to the end of the <head>, or at least before the links that reference /skins/blue/main.css and /skins/default/main.css (it will block their download).
  • On the forums, move the CSS links before the JavaScript links and section. Consider whether it's possible to place this CSS inline; it's wasteful to have just one definition in a file.
  • The site seems to be using both ga.js and urchin.js. Pick one? You can call it multiple times, see the documentation.
  • Combine all the icons into one CSS sprite, or at least load them from a separate virtual subdomain
  • There's probably a better way of handling stars. You could probably use just one graphic with ten yellow stars on the left and ten grey ones on the right, set it as the background-image for a single element, and shift its background-position to the left or right appropriately.
  • Consider using a completely separate cookie-less domain to host images and other static files (reducing the number of images would make this less necessary here too)

Rules, tools and more[edit]