High Performance Web Sites 14 rules for faster pages Steve Souders Chief Performance Yahoo! souders@yahoo-inc.com

Exceptional Performance quantify and improve the performance of all Yahoo! products worldwide center of expertise build tools, analyze data gather, research, and evangelize best practices

Scope performance breaks into two categories response time efficiency current focus is response time of web products coming up next: mobile, backend

The Importance of Frontend Performance Backend = 5% Frontend = 95% Even primed cache, frontend = 88%

Time Spent on the Frontend Empty Cache Primed Cache amazon.com 82% 86% aol.com 94% cnn.com 81% 92% ebay.com 98% google.com 64% msn.com 97% 95% myspace.com 96% wikipedia.org 80% 88% yahoo.com youtube.com

The Performance Golden Rule 80-90% of the end-user response time is spent on the frontend. Start there. Greater potential for improvement Simpler Proven to work If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

Agenda Performance Research 14 Rules (plus more) Case Studies Evangelism Live Analysis

Performance Research If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

Browser Cache Experiment Add an image to the page: Expires: Thu, 15 Apr 2004 20:00:00 GMT Last-Modified: Wed, 28 Sep 2006 23:49:57 GMT # users with at least one 200 response total # unique users Percentage of users with an empty cache? Percentage of page views with an empty cache? # of 200 responses total # responses

Browser Cache Expt Results users with empty cache page views with empty cache 40-60% ~20% On the first day of the experiment, no one had these images cached so the empty cache percentage was 100%. As the days passed more users had the images cached, so the percentages dropped until at some point it reached a constant steady state.

Experiment Takeaways The empty cache user experience is more prevalent than you think! Optimize for both primed cache and empty cache experience. Strategies such as combining scripts, stylesheets, or images reduce the number of HTTP requests for both an empty and a full cache page view. Configuring components to have an Expires header with a date in the future reduces the number of HTTP requests for only the full cache page view.

Impact of Cookies on Response Time Cookie Size Time Delta 0 bytes 78 ms 0 ms 500 bytes 79 ms +1 ms 1000 bytes 94 ms +16 ms 1500 bytes 109 ms +31 ms 2000 bytes 125 ms +47 ms 2500 bytes 141 ms +63 ms 3000 bytes 156 ms +78 ms The performance team at Yahoo! ran an experiment to measure the impact of retrieving a document with various cookie sizes. The experiment measured a static HTML document with no elements in the page. The primary variable in the experiment was the cookie size. We ran the experiment using a test harness that fetches a set of URLs repeatedly while measuring how long it takes to load the page on DSL. These results highlight the importance of keeping the size of cookies as low as possible to minimize the impact on the user’s response time. A 3000 byte cookie, or multiple cookies that total 3000 bytes, could add as much as an 80 ms delay for users on DSL bandwidth speeds. The delay is even worse for users on dial-up. keep sizes low 80 ms delay dialup users

Experiment Takeaways eliminate unnecessary cookies keep cookie sizes low set cookies at appropriate domain level set Expires date appropriately earlier date or none removes cookie sooner Setting cookies at the appropriate path and domain is just as important as the size of the cookie, if not more. A cookie set at the .yahoo.com domain impacts the response time for every Yahoo! page in the .yahoo.com domain that a user visits. Eliminate unnecessary cookies. Keep cookie sizes as low as possible to minimize the impact on the user response time. Be mindful of setting cookies at the appropriate domain level so other sub-domains are not affected. Set an Expires date appropriately. An earlier Expires date or none removes the cookie sooner, improving the user response time.

Parallel Downloads Two in parallel Four in parallel Eight in parallel If a web page evenly distributed its components across two hostnames, the overall response time would be about twice as fast. The HTTP requests would look as shown in Figure 2, with four components downloaded in parallel (two per hostname). The horizontal width of the box is the same, to give a visual cue as to how much faster this page loads. Limiting parallel downloads to two per hostname is a guideline. By default, both Internet Explorer and Firefox follow the guideline, but users can override this default behavior. Internet Explorer stores the value in the Registry Editor. (See Microsoft Help and Support.) Firefox’s setting is controlled by the network.http.max-persistent-connections-per-server setting, accessible in the about:config page. It’s interesting to note that for HTTP/1.0, Firefox’s default is to download eight components in parallel per hostname. Figure 3 shows what it would look like to download these ten images if Firefox’s HTTP/1.0 settings are used. It’s even faster than Figure 2, and we didn’t have to split the images across two hostnames. Instead of relying on users to modify their browser settings, front-end engineers could simply use CNAMEs (DNS aliases) to split their components across multiple hostnames.

Maximizing Parallel Downloads response time (seconds) In our experiment, we vary the number of aliases: 1, 2, 4, 5, and 10. This increases the number of parallel downloads to 2, 4, 8, 10, and 20 respectively. We fetch 20 smaller-sized images (36 x 36 px) and 20 medium-sized images (116 x 61 px). To our surprise, increasing the number of aliases for loading the medium-size images (116 x 61px) worsens the response times using four or more aliases. Increasing the number of aliases by more than two for smaller-sized images (36 x 36px) doesn’t make much of an impact on the overall response time. aliases

Maximizing Parallel Downloads response time (seconds) On average, using two aliases is best. One possible contributor for slower response times is the amount of CPU thrashing on the client caused by increasing the number of parallel downloads. The more images that are downloaded in parallel, the greater the amount of CPU thrashing on the client. On my laptop at work, the CPU jumped from 25% usage for 2 parallel downloads to 40% usage for 20 parallel downloads. These values can vary significantly across users’ computers but is just another factor to consider before increasing the number of aliases to maximize parallel downloads. These results are for the case where the domains are already cached in the browser. In the case where the domains are not cached, the response times get significantly worse as the number of hostname aliases increases. For web pages desiring to optimize the experience for first time users, we recommend not to increase the number of domains. To optimize for the second page view, where the domains are most likely cached, increasing parallel downloads does improve response times. The choice depends on which scenario was most typical. domain names caching. Another issue to consider is that DNS lookup times vary significantly across ISPs and geographic locations. Typically, DNS lookup times for users from non-US cities are significantly higher than those for users within the US. If a good percentage of your users are coming from outside the US, the benefits of increasing parallel downloads is offset by the time to make many DNS lookups. rule of thumb: use at least two but no more than four aliases aliases

Experiment Takeaways consider the effects of CPU thrashing DNS lookup times vary across ISPs and geographic locations domain names may not be cached

14 Rules

14 Rules Make fewer HTTP requests Use a CDN Add an Expires header Gzip components Put stylesheets at the top Move scripts to the bottom Avoid CSS expressions Make JS and CSS external Reduce DNS lookups Minify JS Avoid redirects Remove duplicate scripts Configure ETags Make AJAX cacheable in priority order addressing these rules improve response times

Rule 1: Make fewer HTTP requests CSS sprites combined scripts, combined stylesheets preloading image maps inline images CSS sprites is the best soln, but I arranged these in order of complexity. Sometimes there's a tension or tradeoff between richer content and performance. One of the few rules that improves response times for first-time (empty cache) visitors (~20% of page views, 40-60% of unique users).

CSS Sprites size of combined image is less <span style=" background-image: url('sprites.gif'); background-position: -260px -90px;"> </span> Size of combined image actually decreases due to reduced image overhead (color tables, formatting info, etc.). size of combined image is less http://alistapart.com/articles/sprites

Combined Scripts, Combined Stylesheets amazon.com 3 1 aol.com 18 cnn.com 11 2 ebay.com 7 froogle.google.com msn.com 9 myspace.com wikipedia.org yahoo.com 4 youtube.com Average 6.5 1.5

Combined Scripts, Combined Stylesheets combining six scripts into one eliminates five HTTP requests challenges: develop as separate modules number of possible combinations vs. loading more than needed maximize browser cache one solution: dynamically combine and cache

Preloading Download resources for the next page after the current page is done loading. Examples: http://www.google.com http://search.yahoo.com

Image maps server-side client-side – preferred drawbacks: <a href="navbar.cgi"><img ismap src="imagemap.gif"></a> → http://.../navbar.cgi?127,13 client-side – preferred <img usemap="#map1" border=0 src="/images/imagemap.gif"> <map name="map1"> <area shape="rect" coords="0,0,31,31" href="home.html" title="Home"> … </map> drawbacks: must be contiguous defining area coordinates – tedious, errors Client-side is preferred: provide visual feedback of what image portions are active, accessible to people with non-graphical browsers http://www.w3.org/TR/html401/struct/objects.html#h-13.6

Inline Images data: URL scheme not supported in IE data:[<mediatype>][;base64],<data> <IMG ALT=”Red Star” SRC="data:image/gif;base64,R0lGODlhDAAMALMLAPN8ffBiYvWWlvrKy/FvcPewsO9VVfajo+w6O/zl5estLv/8/AAAAAAAAAAAAAAAACH5BAEAAAsALAAAAAAMAAwAAAQzcElZyryTEHyTUgknHd9xGV+qKsYirKkwDYiKDBiatt2H1KBLQRFIJAIKywRgmhwAIlEEADs="> not supported in IE avoid increasing size of HTML pages: put inline images in cached stylesheets Spec says "allows inclusion of small data items as 'immediate' data." Mostly used for images, but can be used anywhere a URL is specified: A and SCRIPT They say there are size limitations, but FF supports up to 100K base64 encoding increases size of images Since HTML pages are typically not cached, move inline images to cached stylesheets. http://tools.ietf.org/html/rfc2397

Rule 2: Use a CDN amazon.com Akamai aol.com cnn.com ebay.com Akamai, Mirror Image google.com msn.com SAVVIS myspace.com Akamai, Limelight wikipedia.org yahoo.com youtube.com distribute your static content before distributing your dynamic content backups, extended storage capacity, caching, absorb spikes drawbacks: affected by other sites, no direct control Homegrown solutions are also used. Cut 20% for Shopping.

Rule 2: Use a CDN Adding your CDN(s) to YSlow Go to about:config Right-click in the window and choose New and String to create a new string preference. Enter extensions.firebug.yslow.cdnHostnames for the preference name. For the string value, enter the hostname of your CDN, for example, mycdn.com. Do not use quotes. If you have multiple CDN hostnames, separate them with commas. backups, extended storage capacity, caching, absorb spikes drawbacks: affected by other sites, no direct control Homegrown solutions are also used. Cut 20% for Shopping.

Rule 3: Add an Expires header not just for images Images Stylesheets Scripts % with Expires Median Age amazon.com 0/62 0/1 0/3 0% 114 days aol.com 23/43 1/1 6/18 48% 217 days cnn.com 0/138 0/2 2/11 1% 227 days ebay.com 16/20 0/7 55% 140 days froogle.google.com 1/23 4% 454 days msn.com 32/35 3/9 80% 34 days myspace.com 0/18 1 day wikipedia.org 6/8 2/3 75% yahoo.com 23/23 4/4 100% n/a youtube.com 0/32 26 days One thought: you can't put an Expires header because the content is constantly changing. But when we look at the Last-Modified header we see that's not the case. For MySpace it is, but Amazon, CNN, Froogle and YouTube all have lengthier Last_modified values.

you can affect users' download times Rule 4: Gzip components you can affect users' download times 90%+ of browsers support compression

Gzip: not just for HTML HTML Scripts Stylesheets amazon.com x aol.com some cnn.com ebay.com froogle.google.com msn.com deflate myspace.com wikipedia.org yahoo.com youtube.com gzip scripts, stylesheets, XML, JSON (not images, PDF) Images and PDF files are already compressed. Gzipping them wastes CPU and can increase file sizes.

Gzip vs. Deflate Gzip compresses more Gzip supported in more browsers Size Savings Script 3.3K 1.1K 67% 66% 39.7K 14.5K 64% 16.6K 58% Stylesheet 1.0K 0.4K 56% 0.5K 52% 14.1K 3.7K 73% 4.7K

Gzip Configuration Apache 2.x: mod_deflate HTTP request HTTP response AddOutputFilterByType DEFLATE text/html text/css application/x-javascript HTTP request Accept-Encoding: gzip, deflate HTTP response Content-Encoding: gzip Vary: Accept-Encoding The Vary header is required for proxies, so they don't server gzip to browsers that don't support it (and vice-versa). The Vary header is added automatically by mod_gzip (not sure about mod_deflate). needed for proxies

Gzip Edge Cases <1% of browsers have problems with gzip IE 5.5: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q313712 IE 6.0: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q31249 Netscape 3.x, 4.x http://www.schroepl.net/projekte/mod_gzip/browser.htm consider adding Cache-Control: Private remove ETags (Rule 13) hard to diagnose; problem getting smaller

Rule 5: Put stylesheets at the top stylesheets block rendering in IE solution: put stylesheets in HEAD (per spec) avoids Flash of Unstyled Content use LINK (not @import) Unfortunately, this is bad for FF because in FF stylesheets block parallel downloads.

Slowest is Fastest CSS at the bottom: CSS at the top: resources load faster, but nothing renders CSS at the top: resources take longer, but render progressively right choice REMEMBER: IE ONLY! css-top seems the fastest, but actually it's the slowest to download all necessary components to render the page css-top-import shows that using @import puts the stylesheet last thus delaying rendering @import at the top: same problems as bottom

Rule 6: Move scripts to the bottom scripts block parallel downloads across all hostnames scripts block rendering of everything below them in the page script defer attribute is not a solution blocks rendering and downloads in FF slight blocking in IE

Rule 7: Avoid CSS expressions used to set CSS properties dynamically in IE width: expression( document.body.clientWidth < 600 ? “600px” : “auto” ); problem: expressions execute many times mouse move, key press, resize, scroll, etc. alternatives: one-time expressions event handlers

One-Time Expressions expression overwrites itself <style> P { background-color: expression(altBgcolor(this)); } </style> <script> function altBgcolor(elem) { elem.style.backgroundColor = (new Date()).getHours()%2 ? "#F08A00" : "#B8D4FF"; </script>

Event Handlers tie behavior to (fewer) specific events window.onresize = setMinWidth; function setMinWidth() { var aElements = document.getElementsByTagName("p"); for ( var i = 0; i < aElements.length; i++ ) { aElements[i].runtimeStyle.width = ( document.body.clientWidth<600 ? "600px" : "auto" ); } Could do this only for MSIE browser type.

Rule 8: Make JS and CSS external inline: HTML document is bigger external: more HTTP requests, but cached variables page views per user (per session) empty vs. primed cache stats component re-use external is typically better extra credit: post-onload download, dynamic inlining

Post-Onload Download inline in front page download external files after onload window.onload = downloadComponents; function downloadComponents() { var elem = document.createElement("script"); elem.src = "http://.../file1.js"; document.body.appendChild(elem); ... } speeds up secondary pages

Dynamic Inlining start with post-onload download set cookie after components downloaded server-side: if cookie, use external else, do inline with post-onload download cookie expiration date is key speeds up all pages

Rule 9: Reduce DNS lookups typically 20-120 ms block parallel downloads OS and browser both have DNS caches

Adding DNS Lookups Increasing parallel downloads is worth an extra DNS lookup.

TTL (Time To Live) TTL – how long record can be cached www.amazon.com 1 minute www.aol.com www.cnn.com 10 minutes www.ebay.com 1 hour www.google.com 5 minutes www.msn.com www.myspace.com www.wikipedia.org www.yahoo.com www.youtube.com TTL – how long record can be cached browser settings override TTL

Browser DNS Cache IE Firefox DnsCacheTimeout: 30 minutes KeepAliveTimeout: 1 minute ServerInfoTimeout: 2 minutes Firefox network.dnsCacheExpiration: 1 minute network.dnsCacheEntries: 20 network.http.keep-alive.timeout: 5 minutes Fasterfox: 1 hour, 512 entries, 30 seconds

Reducing DNS Lookups fewer hostnames – 2-4 keep-alive

Rule 10: Minify JavaScript Minify External? Minify Inline? www.amazon.com no www.aol.com www.cnn.com www.ebay.com yes froogle.google.com www.msn.com www.myspace.com www.wikipedia.org www.yahoo.com www.youtube.com minify inline scripts, too

Minify vs. Obfuscate minify – it's safer Original JSMin Savings Dojo Savings www.amazon.com 204K 31K (15%) 48K (24%) www.aol.com 44K 4K (10%) www.cnn.com 98K 19K (20%) 24K (25%) www.myspace.com 88K 23K (27%) 24K (28%) www.wikipedia.org 42K 14K (34%) 16K (38%) www.youtube.com 34K 8K (22%) 10K (29%) Average 85K 17K (21%) 21K (25%) minify – it's safer minify instead of obfuscate: fewer bugs, less maintenance, easier to debug in production after gzipping, no difference between minification and obfuscation not much difference http://crockford.com/javascript/jsmin http://dojotoolkit.org/docs/shrinksafe

Rule 11: Avoid redirects 3xx status codes – mostly 301 and 302 HTTP/1.1 301 Moved Permanently Location: http://stevesouders.com/newuri add Expires headers to cache redirects worst form of blocking example: http://toolbar.google.com

Redirects Redirects www.amazon.com no www.aol.com yes – secondary page www.cnn.com yes – initial page www.ebay.com froogle.google.com www.msn.com www.myspace.com www.wikipedia.org www.yahoo.com www.youtube.com

Avoid Redirects missing trailing slash mod_rewrite CNAMEs http://astrology.yahoo.com/astrology use Alias or DirectorySlash mod_rewrite CNAMEs log referer – track internal links outbound links – harder beacons – beware of race condition XHR – bail at readyState 2 With alias, DirectorySlash and mod_rewrite you can't have URIs that are relative to the current directory.

Rule 12: Remove duplicate scripts hurts performance extra HTTP requests (IE only) extra executions atypical? 2 of 10 top sites contain duplicate scripts team size, # of scripts extra HTTP requests happen in IE if the scripts are not cacheable or if the page is Reloaded

Script Insertion Functions <?php function insertScript($jsfile) { if ( alreadyInserted($jsfile) ) { return; } pushInserted($jsfile); if ( hasDependencies($jsfile) ) { $dependencies = getDependencies($jsfile); for ( $i = 0; $i < count($dependencies); $i++ ) { insertScript($dependencies[$i]); } echo '<script type="text/javascript" src="' . getVersion($jsfile) . '"></script>"; ?> avoids dupes, makes sure dependencies are included in the right order, handles versioning could do combining

Rule 13: Configure ETags unique identifier returned in response ETag: "c8897e-aee-4165acf0" Last-Modified: Thu, 07 Oct 2004 20:54:08 GMT used in conditional GET requests If-None-Match: "c8897e-aee-4165acf0" If-Modified-Since: Thu, 07 Oct 2004 20:54:08 GMT if ETag doesn't match, can't send 304 ETag format Apache: inode-size-timestamp IIS: Filetimestamp:ChangeNumber Use 'em or lose 'em Apache: FileETag none IIS: http://support.microsoft.com/kb/922703/ ETag == entity tag if-none-match overrides if-modified-since

Rule 14: Make AJAX cacheable XHR, JSON, iframe, dynamic scripts can still be cached (and minified, and gzipped) a personalized response should still be cacheable for that person

AJAX Example: Yahoo! Mail Beta address book XML request → GET /yab/[...]&r=0.5289571053069156 HTTP/1.1 Host: us.xxx.mail.yahoo.com ← HTTP/1.1 200 OK Date: Thu, 12 Apr 2007 19:39:09 GMT Cache-Control: private,max-age=0 Last-Modified: Sat, 31 Mar 2007 01:17:17 GMT Content-Type: text/xml; charset=utf-8 Content-Encoding: gzip address book changes infrequently cache it; add last-modified-time in URL 18K for me!

Next Rules Split static content across multiple domains Reduce the size of cookies Host static content on a different domain Minify CSS Avoid IFrames in priority order addressing these rules improve response times

Case Studies If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

Case Study: move JS to onload remove bottom tabs avoid redirects image sprites host JS on CDN combine JS files 40-50% top graph: response times over dialup bottom graph: response times over broadband

What about performance and Web 2.0 apps? client-side CPU is more of an issue user expectations are higher these rules still apply, new rules will come out start off on the right foot

Case Study: Mail Classic Mail User Workflow mail.yahoo.com view inbox folder read messages (x3) compose message confirm send total time: Time 2.40 s 4.98 s 6.39 s 2.21 s 2.10 s 18.08 s Time 12.48 s 1.52 s 1.53 s 0.34 s 0s 15.87 s Delta +420% -70% -76% -85% -100% -12%

Evangelism If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

Evangelism Book Conferences Blogs Open Source YSlow High Performance Web Sites Conferences Yahoo! F2E Summit Web 2.0 Expo Rich Web Experience Blogs YUI Blog: http://yuiblog.com/blog/category/performance YDN Blog: http://developer.yahoo.com/performance/ Open Source YSlow OSCon Ajax Experience Blogher Future of Web Apps halo effect helps all web users documentation archive hiring communications w/in the company perceived value quality of end product (book, code)

YSlow http://developer.yahoo.com/yslow performance lint tool scores web pages for each rule Firefox add-on integrated with Firebug open source license Knew we couldn't reach all the development teams at Yahoo!. Needed to teach them to fish.

Ten Top U.S Web Sites Page Weight Response Time YSlow Grade www.amazon.com 405K 15.9 sec D www.aol.com 182K 11.5 sec F www.cnn.com 502K 22.4 sec www.ebay.com 275K 9.6 sec C froogle.google.com 18K 1.7 sec A www.msn.com 221K 9.3 sec www.myspace.com 205K 7.8 sec www.wikipedia.org 106K 6.2 sec www.yahoo.com 178K 5.9 sec www.youtube.com 139K

Strong Correlation correlation(resp time, page weight) = 0.94 total page weight response time inverse YSlow grade Yahoo! doesn't quite follow the curve. It has the 2nd best YSlow grade[1] and response time, even though it's the 4th heaviest page. The Yahoo! front page team is a long-time consumer of these performance best practices, and therefore scores well in YSlow and is able to squeeze more speed out of their page. Amazon's YSlow grade also doesn't reflect the page weight and response time. The main reason for this is the large number of images in their page (approximately 74 images). YSlow doesn't subtract points for images, so the Amazon page scores well but performs slowly. Web 2.0 challenges correlation(resp time, page weight) = 0.94 correlation(resp time, inverse YSlow) = 0.76

Live Analysis If you could cut performance in half, FE changes would be 40-45%, while BE would be only 5-10%. BE changes are typically more complex: rearchitecture, optimize code, add/modify hw, distribute databases, etc. FE is simpler: change web server config, place scripts and stylesheets differently in the page, combine requests, etc. At Yahoo!, we've cut response times on 50 properties, often by 25% or more.

IBM Page Detailer packet sniffer Windows only IE, FF, any .exe c:\windows\wd_WS2s.ini Executable=(NETSCAPE.EXE),(NETSCP6.EXE),(firefox.exe) free trial, $300 license http://alphaworks.ibm.com/tech/pagedetailer

http://alphaworks.ibm.com/tech/pagedetailer

Firebug web development evolved inspect and edit HTML tweak and visualize CSS debug and profile JavaScript monitor network activity (caveat) Firefox extension free http://getfirebug.com/

Takeaways focus on the frontend harvest the low-hanging fruit you do control user response times small investment up front keeps on giving LOFNO – be an advocate for your users

Steve Souders souders@yahoo-inc.com

CC Images Used "Need for Speed" by Amnemon: http://www.flickr.com/photos/marinacvinhal/379111290/ "Max speed 15kmh" by xxxtoff: http://www.flickr.com/photos/xxxtoff/219781763/ "maybe" by Tal Bright: http://www.flickr.com/photos/bright/118197469/ "takeout" by dotpolka: http://www.flickr.com/photos/dotpolka/249129144/ "how do they do that" by Fort Photo: http://www.flickr.com/photos/fortphoto/388825145/ "Absolutely Nothing is Allowed Here" by Vicki & Chuck Rogers: http://www.flickr.com/photos/two-wrongs/205467442/ "Zipper Pocket" by jogales: http://www.flickr.com/photos/jogales/11519576/ "new briefcase" by dcJohn: http://www.flickr.com/photos/dcjohn/85504455/ "Told you it was me!" by Pug!: http://flickr.com/photos/pugspace/1277023154/ "Robert's Legion" by dancharvey: http://www.flickr.com/photos/dancharvey/2647529/ "thank you" by nj dodge: http://flickr.com/photos/nj_dodge/187190601/