Slide 1

2013 AKAMAI | FASTER FORWARD TM Web Performance Best Practices Fast Sites for a Global Audience San Mateo Meetup, December 5, 2013 Slide 2 2013 AKAMAI | FASTER FORWARD TM Welcome! Introduction Who We Are Why Performance Matters Web Performance Best Practices Measured vs Perceived Performance Well-known Best Practices Using a CDN Practical Considerations Some Real-World Use Cases Slide 3 2013 AKAMAI | FASTER FORWARD TM Who We Are Javier Garza Enterprise Architect jgarza@akamai.com David Bartosh Enterprise Architect dbartosh@akamai.com Slide 4 2013 AKAMAI | FASTER FORWARD TM Why Web Site Performance Matters Gomez For e-commerce, conversion rate increases 74% when page load time decreases from 8 to 2 seconds.* Computer and Equation Research 71% of mobile web users expect website performance on their mobile phones to be equal to, or better than, what they experience on their desktops -- up from 58% in 2009.* Google Is incorporating page performance data in its ranking.** * Source http://newsletter.sli-systems.com/2012/04 ** Source http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html Slide 5 2013 AKAMAI | FASTER FORWARD TM But Web Site Complexity is Always Increasing Source: Ilya Grigorik Our applications are complex, and growing Slide 6 2013 AKAMAI | FASTER FORWARD TM Measured vs. Perceived Performance Slide 7 2013 AKAMAI | FASTER FORWARD TM Quick Review of Browser Behaviors The One Rule: Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved. Javascript CSS Long load times Slide 8 2013 AKAMAI | FASTER FORWARD TM Rule #1: Scripts Block Parsing Posit: JavaScript is a single-threaded environment, and changes the DOM Consequence: The render chain blocks. Result: The browser will sit there parsing it all. Conclusion: Dont do that. Use async/defer where you can. * HTML5 JavaScript Workers change this a bit Slide 9 2013 AKAMAI | FASTER FORWARD TM Rule #2: Style Sheets Block Rendering Posit: Anything that can force a re-flow will introduce uncertainty. Consequence: CSS blocks rendering Result: Inline or interspersed CSS will block rendering. Conclusion: Pare it down, put it first. * CSS print styles or non-matching media selectors will not block because theyre not immediately applicable. Slide 10 2013 AKAMAI | FASTER FORWARD TM Rule #3: Less Caching, More Problems. Posit: The fastest load time is when the browser already has the data (in cache). Consequence: Origin hits cost time and are distance-based. Result: Non-cacheable content creates high variability in page load time. Conclusion: Cache browser-side if possible, consider using a CDN. * Really, any CDN will be better than none, although the author might have certain biases. Slide 11 2013 AKAMAI | FASTER FORWARD TM Measured Performance: Definition Performance is typically measured by the elapsed time between the navigationStart event (after the browser has unloaded the current document) and the start of the "onload" event (loadEventStart) for the new page, after all resources (HTML, images, CSS, JavaScript) have been downloaded. Source: W3C Slide 12 2013 AKAMAI | FASTER FORWARD TM Measured Performance: Standard Optimizations Use compression, consolidate and minimize (minify) text files (CSS, HTML, JavaScript) Use sprites for small images Only include resources the page actually requires Minimize header payloads, for example, by using different domains for static objects to avoid unnecessary client cookies Slide 13 2013 AKAMAI | FASTER FORWARD TM Measured Performance: Standard Optimizations Use resource inlining and domain sharding (use shards with caution on mobile-centric or responsive sites) Maintain persistent connections (HTTP keep-alive) Now make it global Leverage a Content Distribution Network (CDN) for static object caching close to users, for route optimization, and for additional content acceleration techniques (object/page prefetching, advanced failover, etc.) Slide 14 2013 AKAMAI | FASTER FORWARD TM Perceived Performance: What is it? No browser-independent, agreed upon metric as of yet. Loosely defined as either when all elements in viewing area have been painted or when user sees enough information to interact with the site. WebPageTest.org uses the % of viewport paint completion as a metric. There is usually a strong correlation between measured and perceived performance. If care is not given to perceived performance, user experience can be negatively impacted, even if real performance metrics are positive. Slide 15 2013 AKAMAI | FASTER FORWARD TM Perceived Performance: Standard Optimizations Maximize downstream Time-to-Live (TTL) browser cache cant be purged, so make static object filenames unique (fingerprinting) and use an infinite TTL. Make JavaScript asynchronous, remove from HTML, and avoid DOM modification via script wherever possible. Reduce the number of domains used (especially third party domains). Optimize images by reducing quality and using progressive rendering, and use lazy-loading for content below the fold. Continually evaluate cookie collection/size and usage. Slide 16 2013 AKAMAI | FASTER FORWARD TM Waterfall without Front-End Optimizations 7.066s Waterfall with Front-End Optimizations 3.044s 56.9% Faster When Measured and Perceived Meet Slide 17 2013 AKAMAI | FASTER FORWARD TM When Measured and Perceived Meet Slide 18 2013 AKAMAI | FASTER FORWARD TM Well-Known Best Practices (Thank you, Steve Souders!) Slide 19 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Optimizing caching keeping your application's data and logic off the network altogether Optimizing caching Minimizing round-trip times reducing the number of serial request-response cycles Minimizing round-trip times Minimizing request overhead reducing upload size Minimizing request overhead Minimizing payload size reducing the size of responses, downloads, and cached pages Minimizing payload size Optimizing browser rendering improving the browser's layout of a page Optimizing browser rendering Optimizing for mobile tuning a site for the characteristics of mobile networks and mobile devices Optimizing for mobile As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro Slide 20 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Optimizing caching keeping your application's data and logic off the network altogether Optimizing caching As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro /style-Bb752799d39de9dc7c186802ea1eaf84.css /logo-E8f51d6221bcc66b381c3b72619bce70.jpg /notify-40d68a1163b9870406ba588709f1507f.js Akamai FEO automation can create fingerprinted filenames automatically for your static content, both in browser cache and HTML5 local storage. Slide 21 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Minimizing round-trip times reducing the number of serial request-response cycles Minimizing round-trip times Number of Domains Number of Requests (Combining Images, CSS + JS)* Order of Styles and Scripts** Prefer Asynchronous Resources*** * http://www.yourinspirationweb.com/en/how-to-increase-the-performance-of-a-website-with-css-sprites/ ** https://developers.google.com/speed/docs/best-practices/rules_intro *** https://www.daycounts.com/shop/plugins/javascript-async-defer-detail Akamai System Scripts take content inlined into the initial HTML request and writes individual objects to HTML5 Local Storage, and on subsequent requests, the returned HTML will refer to the files in Local Storage (not inlined any more). Slide 22 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Minimizing request overhead reducing upload size Minimizing request overhead As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro Cookie: wlp=A|9a0z-t:a*+1g6CQ._:h*lrY/CQ.Color_Blue; MUID=3FBEECBBE1D462AD1F5CE989E2D46209; skyjsTabId=1; skyjsTabActive=1; s_vsn_skyperendezvous-ol=4603398481849; wla42=; mbox=PC#1385500405328-646453.19_29#1387247853|check#true#1386038313|session#1386038252124-984802#1386040113; wlidperf=throughput=1&latency=3182&FR=L&ST=1386038256477; PPLState=1; MSPAuth=2F0Y29nBUFxm7S9ASH3z2lLAth15kHwIwL1KyC4yK046ahVQwZDYQbJBeV!cg2qbSxQdTe1EE4GRfagxkWSBMpyngFmo3HpzZPuBJupcgtw3pDPzBL74CDo!rKNwBAc69C; MSPProf=2P3tLXVLvD5PVHLGWbCJkyyz2zUlu3ArRRE!IATPEx6Lj0r*Rlk1M4nbsRK4nBWLj!OxvgmcXA1dSlpaqdNSl0owO4pf82cyoyvPFXHdPOKTj3qlPTloZ!o2AqTrgbXHXSGBpQpbXC4Ly8AB2qpig8NjC1pLhoia5 ozL0AOBCf2SwTgL6lZsBuXw8dw!0svabs; MH=MSFT; NAP=V=1.9&E=e82&C=huQrfRMnexbMCcpHS0BySjtbjvEyN1GuaLdH0Kh6Cee6lRbLiO-vFw&W=1; ANON=A=3E85CA0A4818AE1ED161F41CFFFFFFFF&E=edc&W=1; WLSSC=EgBoAQMAAAAEgAAAC4AAzvFu5rZSyzMqMXKWSXmyWGn9ZCGR5falZIwVi2xH/Q3xVyRFyEP4y6WtH4FG+z3B2UdZO2RMq3VXs/RBt30W2lRO4tReO8U9/WrpMc1jiFsZ+BvN049A8A5MNrS5ZwI/Nolei8 lac+0fVOXApuAj0ZThAzo/lkHi3bCqo+QiDVDXAGAA1wCnGwEAhF0vTPBDnVLwQ51SECcAAAoQoAAwFQBkYmFydG9zaEBob3RtYWlsLmNvbQBQAAAUZGJhcnRvc2hAaG90bWFpbC5jb20AAAAwVVMABTk4MTI 2AACMAQQJAgAAY6lNQBAUQwAFRGF2aWQAB0JhcnRvc2gEXwABVwAAAAAAAAAAAADo3uAljZVmMQAA8EOdUvC4r1IAAAAAAAAAAAAAAAANADIzLjc5LjIzMS4xNAAFAAAAAAAAAAAAAAAAAAEAAAEAA AEAAAEAAAAAAAAAAAAA; KVC=17.1.7118.6000; mt=01_92dabd989a36d9368a0e72467d6753cdca3acb4d8a9cd64efdfc8115d43f7526|fc178b0adc439c31; xid=9d3b00b0-d585-45f1-b738- fa8c9a3439ee&kN00L&BLU171-W139&387; xidseq=1; mkt=en-US; upcb=0; crms=0TT; E=P:Os7JxOe90Ig=:8GE3Qx3nk8d4RNR/cT7kfHiXHC4ln+WgWmOeOAU75ho=:F; wls=A|9a0z-t:a*n:h*m; wlv=A|9a0z- d:s*c8EjCw.2+1+0+3; KSC=hAkdcx8gQ3v4FwX6sdiZqXaUNKgJo7mN5SzCdNslc9U01J2136YD84NZemf0hnZMowvivG8wg5XM4yygTsbXu4NT5Wz2CryD5le3rIWOqSum2aXAlr3UstPHjSSOExRnEb2RhgbW2oo7rRBoLQyTZtFoaBIDBv83 1JobVdAziWTcD5uuPdiBcOOaQ7sV5Qu/Hbex+Z0KadcseA68mEch2F8pB7vztpR52JRcFeK7CiWygf2BnwjDhTdlBJ75mz9l7lc5gE6NN1KtvuVP9TfjotlutGJVn/OrLuJA8wjbI98lYim7TdIexDc1g+mY69CZ5WjTfa0Mf3Z2 QgtTAduFPryW9k1ai2ri63JM4asV/Rc=; UIC=qskPgrnnjKiZI9+FNXn56C/PNAyeb+XFUVpDJqywbBdsvGNV9m+luxr4vBh+mVPldxZWEx5Mzze5g7lG7xwtk9u1TuJf1FvGbt1p9G6eE4bwj/SbxGefa1vBF00NYdKf; HIC=8d956631e8dee025|0|35|blu171|1761|blu171 Cookie: MSPProf=2P3tLXVLvD5PVHLGWbCJkyyz2zUlu3ArRRE!IATPEx6Lj0r*Rlk1M4nbsRK4nBWLj!OxvgmcXA1dSlpaqdNSl0owO4pf82cyoyvPFXHdPOKTj3qlPTloZ!o2AqTrgbXHXSGBpQpbXC4Ly8AB2qpig8NjC1pLhoia5ozL0AOBCf2SwTgL6lZsBuXw8dw!0svabs 2KB 0.2KB My Windows Live ID Cookie: Keep that all on the server, and know me by an identifier cookie: And use cookie-less domains for static content: 0.0KB Akamai FEO automation automatically creates cookie-less shards for optimized resources using different domains; the number of shards is configurable. Slide 23 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Minimizing payload size reducing the size of responses, downloads, and cached pages Minimizing payload size Example minified script: http://www.crockford.com/javascript/jsmin.htmlhttp://www.crockford.com/javascript/jsmin.html As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro // is.js // (c) 2001 Douglas Crockford // 2001 June 3 // is // The -is- object is used to identify the browser. Every browser edition // identifies itself, but there is no standard way of doing it, and some of // the identification is deceptive. This is because the authors of web // browsers are liars. For example, Microsoft's IE browsers claim to be // Mozilla 4. Netscape 6 claims to be version 5. var is = { ie: navigator.appName == 'Microsoft Internet Explorer', java: navigator.javaEnabled(), ns: navigator.appName == 'Netscape', ua: navigator.userAgent.toLowerCase(), version: parseFloat(navigator.appVersion.substr(21)) || parseFloat(navigator.appVersion), win: navigator.platform == 'Win32' } is.mac = is.ua.indexOf('mac') >= 0; if (is.ua.indexOf('opera') >= 0) { is.ie = is.ns = false; is.opera = true; } if (is.ua.indexOf('gecko') >= 0) { is.ie = is.ns = false; is.gecko = true; } var is={ie:navigator.appName=='Microsoft Internet Explorer',java:navigator.javaEnabled(),ns:navigator.appName=='Netscape',ua:navigat or.userAgent.toLowerCase(),version:parseFloat(navigator.appVersion.substr(21))||pa rseFloat(navigator.appVersion),win:navigator.platform=='Win32'} is.mac=is.ua.indexOf('mac')>=0;if(is.ua.indexOf('opera')>=0){is.ie=is.ns=false;is. opera=true;} if(is.ua.indexOf('gecko')>=0){is.ie=is.ns=false;is.gecko=true;}} 1004B 437B 235B494B 12 3 Minification is part of Akamai FEOs most basic CSS and JS optimizations, which also include automated versioning, fingerprinted filenames and sharding. Slide 24 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Optimizing browser rendering improving the browser's layout of a page. First, some details on CSS selectors. Optimizing browser rendering As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro body * {...} = BAD Avoid a universal key selector ul li {color: blue;} = BAD Use class selectors instead of descendant selectors.unordered-list-item {color: blue;} = BETTER ul#top_blue_nav {...} = BAD Remove redundant qualifiers #top_blue_nav {...} = BETTER body ul li a {...} = BAD (all elements are descendants of the body tag) Avoid using descendant selectors, especially those that specify redundant ancestors Avoid the :hover pseudo-selector for non-link elements for IE clients h3:hover {...} = BAD (for MSIE clients) Important Note! We wont fix bad CSS This ones on your developers! Slide 25 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Optimizing browser rendering contd Optimizing browser rendering Avoid CSS Expressions (deprecated), put CSS in the document head, using the and tags, and don't use @import. Specify image dimensions in the (and/or and ) element or block-level parent, and use dimensions that match those of the actual images (e.g. - dont scale via the front-end). Specify a character set in the HTTP response headers of your HTML documents; the preferred method is to return a Content-Type header with proper charset, or use an HTML meta tag, and if you use both, make sure they match! As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro Akamai has multiple products that compress, resize and deliver according to device and network characteristics automatically. FEO with Responsive Image Loading will create images best suited for mobile devices. Akamai FEO tools will automatically convert @import references into elements. Slide 26 2013 AKAMAI | FASTER FORWARD TM Well-known Best Practices Optimizing for mobile tuning a site for the characteristics of mobile networks and mobile devices Optimizing for mobile Defer parsing of JavaScript or use async (per earlier examples) Make landing page redirects cacheable. What Google says: use a 302 redirect with a cache lifetime of one day, including a Vary: User-Agent header as well as a Cache- Control: private header. What Akamai says (if Akamai is your CDN partner): use a 301 redirect without any Vary header but where Akamais custom User-Agent token (or any Edge Device Characterization feature the origin uses to serve the redirect) is included in the cache key; Akamai will cache the response as if it were a 200, specific to the type of device receiving the redirect. As listed on: https://developers.google.com/speed/docs/best-practices/rules_introhttps://developers.google.com/speed/docs/best-practices/rules_intro Akamai FEO automation intelligently detects script behaviors that modify the page, and those script resources will not be deferred/asyncd. Slide 27 2013 AKAMAI | FASTER FORWARD TM Using a CDN Practical Considerations Slide 28 2013 AKAMAI | FASTER FORWARD TM Using a CDN What you need to know Why should I use a CDN? Page load times, operating costs (bandwidth, infrastructure), SEO ranking, and conversion metrics are all going to improve How do I integrate my site? If your site is static your job is easy. Typically some configuration choices, testing, and a DNS CNAME change. If your site is dynamic, consider using different domain(s) for static content (another best practice). Most CDNs can improve performance and enhanced availability for dynamic content as well. Also uses a DNS CNAME entry for on-boarding, but more extensive testing is recommended. Slide 29 2013 AKAMAI | FASTER FORWARD TM Using a CDN What you need to know Consider things that really help your CDN partners during site design: Use very high downstream TTLs for static content (or use fingerprinted filenames also with a very high TTL), compress text resources at the origin, and consider using cloud storage as well as cookie-less domains Use Cache-Control and/or Expires to control CDN caching; use Edge- Control (Akamai-only) to override all other behaviors Leverage HTML pages that are common across users; personalization (logged in state, shopping cart, product recommendations) can be done asynchronously via script Publish a Last-Modified header for static content (conditional requests) Slide 30 2013 AKAMAI | FASTER FORWARD TM Using a CDN What you need to know Consider things that really help your CDN partners during site design: Dont send a Vary response header (unless you really do Vary) Use your CDN partner for content targeting (localization, device characterization) instead of building out localized origin infrastructure Interesting pre-fetching note: dont use relative paths that reference ancestor directories (e.g. /../../styles.css); at least Akamai servers wont pre-fetch those Slide 31 2013 AKAMAI | FASTER FORWARD TM Case Study 1 Consolidating content for desktop & mobile Slide 32 2013 AKAMAI | FASTER FORWARD TM Case Study 1: Desktop/Mobile consolidation Challenge: Customer wants to consolidate desktop (www.) and mobile (m.) into one Web site Initial page load for mobile devices accessing the www site is slow because of the need of detect & redirect mobile devices at origin Slide 33 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites. Existing infrastructure www.yoursite.com Server 3 rd party Mobile detection engine m.yoursite.com Server yoursite.com/index.htmlyoursite.com/index.html or www.yoursite.com/index.html www.yoursite.com/index.htmlwww.yoursite.com/index.html [desktop site] Origin Redirect to m.yoursite.com/index.html 300ms Slide 34 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites Solution 1: Move Mobile detection and redirect engine closer to end users to avoid extra long round trip (Edge MDR) Performance improvement ~150% Slide 35 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites solution 1 www.yoursite.com Server 3 rd party Mobile detection engine m.yoursite.com Server yoursite.com/index.htmlyoursite.com/index.html or www.yoursite.com/index.html www.yoursite.com/index.htmlwww.yoursite.com/index.html [desktop site] Edge Redirect to m.yoursite.com/index.html 100ms Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname 50ms Slide 36 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites Solution 2: Perform Mobile detection at the Edge but instead of redirecting end user to mobile site, instruct Edge server to pull mobile content from mobile origin site (if not in the cache) and serve to mobile users Performance improvement ~200% (~300% if content is served from the edge cache) Slide 37 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites solution 2 (content not cached) www.yoursite.com Server 3 rd party Mobile detection engine m.yoursite.com Server www.yoursite.com/index.htmlwww.yoursite.com/index.html [mobile version cache-key] www.yoursite.com/index.htmlwww.yoursite.com/index.html [desktop version cache-key] Edge server detects desktop browser and pulls content from www origin server Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname 100ms 50ms Slide 38 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites solution 2 (content cached) www.yoursite.com Server 3 rd party Mobile detection engine m.yoursite.com Server www.yoursite.com/index.htmlwww.yoursite.com/index.html [mobile version cache-key] www.yoursite.com/index.htmlwww.yoursite.com/index.html [desktop version cache-key] Edge server detects desktop browser and pulls content from www origin server Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname 100ms Slide 39 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites Solution 3: Single origin server serves different content for mobile or Desktop users depending on a request parameter Leverage Akamais Edge Device Characterization* (DC) to detect the device type at the Edge and include the device type (i.e. by adding a header) on the request for content to the origin Performance improvement ~200% (~300% if content is served from the edge cache) *DC is built into Edge servers core system to perform mobile detection within a few microseconds. It is so fast that Akamai service performance has allowed to be activated network-wide Slide 40 2013 AKAMAI | FASTER FORWARD TM Case Study 1: consolidating desktop and mobile sites solution 3 (single origin) www.yoursite.com Server 3 rd party Mobile detection engine www.yoursite.com/index.htmlwww.yoursite.com/index.html [mobile version cache-key] www.yoursite.com/index.htmlwww.yoursite.com/index.html [desktop version cache-key] Edge server adds device characteristics to request and origin renders desktop version, cached separately Edge server adds device characteristics to request and origin renders mobile version, cached separately Slide 41 2013 AKAMAI | FASTER FORWARD TM Case Study 2 Offline Origin Server Slide 42 2013 AKAMAI | FASTER FORWARD TM Case Study 2: Offline origin server Challenge: Origin infrastructure cannot handle certain traffic peaks in spite of good cache ratio Upgrading origin components (Load Balancer, application server and DB) will take several months and will costs a lot of money Content relatively static (less than 5% of the content updates more than once a day) Slide 43 2013 AKAMAI | FASTER FORWARD TM Case Study 2: Offline origin server Solution: Serve 100% of traffic out of NetStorage until origin server is upgraded A cron job scrubs locally the DB, finds out files changed since last snapshot (LMT), zips and uploads them to NetStorage where they will be extracted using the CMS SSH shell unzip utility. Solution was meant as a temporary workaround until the origin infrastructure was updated, but worked so well the customer use it for 7 years, accounting for several million dollars in infrastructure savings. Slide 44 2013 AKAMAI | FASTER FORWARD TM Origin Server Case Study 2: Offline origin server NetStorage Origin End user Origin Crawl A cron job creates a complete content archive 1 Content is Uploaded and Expanded Allows for direct updates to files in place 2 End User Requests a Resource 3 4 Content is Served and Cached Slide 45 2013 AKAMAI | FASTER FORWARD TM Case Study 3 Designing CDN-Friendly Sites Slide 46 2013 AKAMAI | FASTER FORWARD TM Case Study 3: Designing CDN Friendly Sites Challenge: Customer MyCRMSite.com was evaluating new Content Management Systems for their marketing site. Part of their criteria was choosing a CMS that is CDN- friendly. Too many features to consider that might have an impact on CDN integration. Slide 47 2013 AKAMAI | FASTER FORWARD TM Case Study 3: Designing CDN Friendly Sites Solution: Final choice came down to the CMS that offered: A fingerprinted filename, which allowed for an infinite downstream TTL (up to one year) Supported configurable domain shards (allowing optimizing for desktop and mobile) Offered the ability to pin each object to a single shard domain (avoiding duplicate objects in all cache tiers). Additional capabilities might be good selling points for a CMS. However, if you are leveraging Akamai FEO automation you dont have to consider these types of optimizations during development. Slide 48 2013 AKAMAI | FASTER FORWARD TM Q&A Slide 49 2013 AKAMAI | FASTER FORWARD TM QR codes Follow us on Twitter Feedback survey http://goo.gl/i2AI64 Slide 50 2013 AKAMAI | FASTER FORWARD TM [Optional] Trick for handling traffic peaks without updating configuration settings Slide 51 2013 AKAMAI | FASTER FORWARD TM Case Study 4: Dealing with traffic peaks Challenge: Customer XYZ has a relatively conservative cache settings with an origin offload of about 80%. However there a few times a year where there are sudden traffic peaks so high that origin cant handle the load. Customer does not want to change the Akamai configuration when this happens as it requires a considerable amount of effort and the effects are not immediate due to the propagation time Slide 52 2013 AKAMAI | FASTER FORWARD TM Case Study 2: Offline origin server Solution: By leveraging the Edge-Control header, the customer is able to instruct Edge servers to cache as instructed by the header value. This is very practical as the effects are immediate and the Edge-Control directive takes precedence over the Akamai configuration. Customer has a couple of UNIX scripts to set this header in emergency situations in a couple of seconds. For example by adding the header on the response, the Edge server will cache the given object for 1 day: Edge-Control: !no-store, max-age=1d See https://control.akamai.com/portal/kb/kbSearchDetails.jsf?articleId=2170 for more details https://control.akamai.com/portal/kb/kbSearchDetails.jsf?articleId=2170 Slide 53 2013 AKAMAI | FASTER FORWARD TM Q&A