1. Web Performance Best Practices
Fast Sites for a Global Audience
San Mateo Meetup, December 5, 2013

2. Welcome! Introduction Web Performance Best Practices
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
Welcome everybody and thanks for coming to this technical talk about Web Performance
In the next 60 minutes David and I will explain why performance matters and share with you a few best practices and a couple of real-world cases where Akamai customers where able to leverage a CDN in a creative way to improve performance and reduce significantly infrastructure costs.
After the talk we will have a Q&A session, and you are more than welcome to stay afterwards to talk to us, grab some more food and drinks and network with other people.

3. Who We Are Javier Garza Enterprise Architect jgarza@akamai.com
David Bartosh
First of all introductions:
My name is Javier Garza, I am an Enterprise Architect aligned to the Advanced Solutions Group and I am working for Akamai for almost 10 years now in Customer Care, Service Enablement and now Professional Services. I also had the opportunity of working for Akamai in different locations like Munich, San Mateo and Honolulu. Before Akamai I worked in different companies in Germany and Spain for about 15 years.
My name is David Bartosh...

4. 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
** Source

5. But Web Site Complexity is Always Increasing
Our applications are complex, and growing…
Source: Ilya Grigorik

6. Measured vs. Perceived Performance

7. 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
Put here the URLs of the external refs

8. 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: Don’t do that. Use async/defer where you can.
* HTML5 JavaScript Workers change this a bit

9. 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 they’re not immediately applicable.

10. 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.

11. 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

12. 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

13. 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.)

14. 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.

15. Perceived Performance: Standard Optimizations
Maximize downstream Time-to-Live (TTL) – browser cache can’t be purged, so make static object filenames unique (fingerprinting) and use an “infinite” TTL.
Make JavaScript asynchronous, remove from HTML <head>, 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.

16. When Measured and Perceived Meet…
Waterfall with Front-End Optimizations
3.044s
56.9% Faster
Waterfall without Front-End Optimizations
7.066s

17. When Measured and Perceived Meet…

18. Well-Known Best Practices
(Thank you, Steve Souders!)

19. Well-known Best Practices
Optimizing caching — keeping your application's data and logic off the network altogether
Minimizing round-trip times — reducing the number of serial request-response cycles
Minimizing request overhead — reducing upload size
Minimizing payload size — reducing the size of responses, downloads, and cached pages
Optimizing browser rendering — improving the browser's layout of a page
Optimizing for mobile — tuning a site for the characteristics of mobile networks and mobile devices
As listed on:

20. Well-known Best Practices
Optimizing caching — keeping your application's data and logic off the network altogether
BROWSER:
Set caching headers aggressively for all static resources.
Use “fingerprinting” to dynamically enable caching.
Set the Vary header correctly for Internet Explorer.
Use the Cache control: public directive to enable HTTPS caching for Firefox.
PROXY CACHING:
Don't include a query string in the URL for static resources.
Don't enable proxy caching for resources that set cookies.
Be aware of issues with proxy caching of JS and CSS files (proxy bugs with “Content-Encoding”).
Akamai FEO automation can create fingerprinted filenames automatically for your static content, both in browser cache and HTML5 local storage.
/style-Bb752799d39de9dc7c186802ea1eaf84.css
/logo-E8f51d6221bcc66b381c3b72619bce70.jpg
/notify-40d68a1163b ba588709f1507f.js
As listed on:

21. Well-known Best Practices
Minimizing round-trip times — reducing the number of serial request-response cycles
Number of Domains
Order of Styles and Scripts**
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).
Number of Requests (Combining Images, CSS + JS)*
MINIMIZE DNS LOOKUPS
The optimal number is somewhere between 1 and 5 hosts (1 main host plus 4 hosts on which to parallelize cacheable resources). As a rule of thumb, you shouldn't use more than 1 host for fewer than 6 resources; fewer than 2 resources on a single host is especially wasteful. It should never be necessary to use more than 5 hosts (not counting hosts serving resources over which you have no control, such as ads).
Use URL paths instead of hostnames wherever possible.
Serve early-loaded JavaScript files from the same hostname as the main document.
MINIMIZE REDIRECTS
Eliminate unnecessary redirects.
Use server rewrites for user-typed URLs.
Track web traffic in the background. Prefer HTTP over JavaScript or meta redirects.
AVOID BAD REQUESTS
Avoid using redirects to handle broken links.
COMBINE EXTERNAL JAVASCRIPT
Partition files optimally.
Partition the JavaScript into 2 files: one JS containing the minimal code needed to render the page at startup; and one JS file containing the code that isn't needed until the page load has completed.
Serve as few JavaScript files from the document <head> as possible, and keep the size of those files to a minimum.
Serve JavaScript of a rarely visited component in its own file. Serve the file only when that component is requested by a user.
For small bits of JavaScript code that shouldn't be cached, consider inlining that JavaScript in the HTML page itself.
Position scripts correctly in the document head. Whether a script is external or inline, it's beneficial to position it in the correct order with respect to other elements (CSS at the top, JS at the bottom), to maximize parallel downloads.
COMBINE EXTERNAL CSS
Partition files optimally. Here are some rules of thumb for combining your CSS files in production:
Partition the CSS into 2 files each: one CSS file containing the minimal code needed to render the page at startup; and one CSS file containing the code that isn't needed until the page load has completed.
Serve CSS of a rarely visited component in its own file. Serve the file only when that component is requested by a user.
For CSS that shouldn't be cached, consider inlining it.
Don't use from a CSS file.
Position stylesheets correctly in the document head. It's beneficial to position references to external CSS in the correct order with respect to scripts (CSS at the top, JS at the bottom), to enable parallel downloads.
COMBINE IMAGES USING CSS SPRITES
Sprite images that are loaded together
Sprite GIF and PNG images first
Sprite small images first
Sprite cacheable images
Using a spriting service
Minimize the amount of "empty space" in the sprited image
Sprite images with similar color palettes
OPTIMIZE THE ORDER OF STYLES AND SCRIPTS
Put external scripts after external stylesheets if possible.
Put inline scripts after other resources if possible.
AVOID DOCUMENT.WRITE
Using document.write() to fetch external resources, especially early in the document, can significantly increase the time it takes to display a web page.
Declare resources directly in HTML markup.
e.g. – like this: <script src="example.js"></script>
And not like this: <script>document.write('<script src="example.js"><\/script>');</script>
Prefer asynchronous resources
Use "friendly iframes“ (A friendly iframe is an iframe on the same origin as its parent document. Resources referenced in friendly iframes load in parallel with resources referenced on the main page.)
AVOID
Using in an external stylesheet can add additional delays during the loading of a web page.
Use the <link> tag instead of
PREFER ASYNCHRONOUS RESOURCES
Fetching resources asynchronously prevents those resources from blocking the page load. JavaScript resources that aren't needed to construct the initial view of the web page, such as those used for tracking/analytics, should be loaded asynchronously.
Use a script DOM element
Load Analytics scripts asynchronously
PARALLELIZE DOWNLOADS ACROSS HOSTNAMES
Serving resources from two different hostnames increases parallelization of downloads.
Balance parallelizable resources across hostnames.
Prevent external JS from blocking parallel downloads.
Always serve a resource from the same hostname (chosen name should be deterministic).
Prefer Asynchronous Resources*** * **
***

22. Well-known Best Practices
Minimizing request overhead — reducing upload size
My Windows Live ID Cookie:
Cookie: wlp=A|9a0z-t:a*+1g6CQ._:h*lrY/CQ.Color_Blue; MUID=3FBEECBBE1D462AD1F5CE989E2D46209; skyjsTabId=1; skyjsTabActive=1; s_vsn_skyperendezvous-ol= ; wla42=; mbox=PC# _29# |check#true# |session# # ; wlidperf=throughput=1&latency=3182&FR=L&ST= ; PPLState=1; MSPAuth=2F0Y29nBUFxm7S9ASH3z2lLAth15kHwIwL1KyC4yK046ahVQwZDYQbJBeV!cg2qbSxQdTe1EE4GRfagxkWSBMpyngFmo3HpzZPuBJupcgtw3pDPzBL74CDo!rKNwBAc69C; MSPProf=2P3tLXVLvD5PVHLGWbCJkyyz2zUlu3ArRRE!IATPEx6Lj0r*Rlk1M4nbsRK4nBWLj!OxvgmcXA1dSlpaqdNSl0owO4pf82cyoyvPFXHdPOKTj3qlPTloZ!o2AqTrgbXHXSGBpQpbXC4Ly8AB2qpig8NjC1pLhoia5ozL0AOBCf2SwTgL6lZsBuXw8dw!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/Nolei8lac+0fVOXApuAj0ZThAzo/lkHi3bCqo+QiDVDXAGAA1wCnGwEAhF0vTPBDnVLwQ51SECcAAAoQoAAwFQBkYmFydG9zaEBob3RtYWlsLmNvbQBQAAAUZGJhcnRvc2hAaG90bWFpbC5jb20AAAAwVVMABTk4MTI2AACMAQQJAgAAY6lNQBAUQwAFRGF2aWQAB0JhcnRvc2gEXwABVwAAAAAAAAAAAADo3uAljZVmMQAA8EOdUvC4r1IAAAAAAAAAAAAAAAANADIzLjc5LjIzMS4xNAAFAAAAAAAAAAAAAAAAAAEAAAEAAAEAAAEAAAAAAAAAAAAA; KVC= ; 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 ; KSC=hAkdcx8gQ3v4FwX6sdiZqXaUNKgJo7mN5SzCdNslc9U01J2136YD84NZemf0hnZMowvivG8wg5XM4yygTsbXu4NT5Wz2CryD5le3rIWOqSum2aXAlr3UstPHjSSOExRnEb2RhgbW2oo7rRBoLQyTZtFoaBIDBv831JobVdAziWTcD5uuPdiBcOOaQ7sV5Qu/Hbex+Z0KadcseA68mEch2F8pB7vztpR52JRcFeK7CiWygf2BnwjDhTdlBJ75mz9l7lc5gE6NN1KtvuVP9TfjotlutGJVn/OrLuJA8wjbI98lYim7TdIexDc1g+mY69CZ5WjTfa0Mf3Z2QgtTAduFPryW9k1ai2ri63JM4asV/Rc=; UIC=qskPgrnnjKiZI9+FNXn56C/PNAyeb+XFUVpDJqywbBdsvGNV9m+luxr4vBh+mVPldxZWEx5Mzze5g7lG7xwtk9u1TuJf1FvGbt1p9G6eE4bwj/SbxGefa1vBF00NYdKf; HIC=8d956631e8dee025|0|35|blu171|1761|blu171
2KB
Keep that all on the server, and know me by an identifier cookie:
Cookie: MSPProf=2P3tLXVLvD5PVHLGWbCJkyyz2zUlu3ArRRE!IATPEx6Lj0r*Rlk1M4nbsRK4nBWLj!OxvgmcXA1dSlpaqdNSl0owO4pf82cyoyvPFXHdPOKTj3qlPTloZ!o2AqTrgbXHXSGBpQpbXC4Ly8AB2qpig8NjC1pLhoia5ozL0AOBCf2SwTgL6lZsBuXw8dw!0svabs
0.2KB
MINIMIZE REQUEST SIZE
Keeping cookies and request headers as small as possible ensures that an HTTP request can fit into a single packet.
Use server-side storage for most of the cookie payload.
Remove unused or duplicated cookie fields.
SERVE STATIC CONTENT FROM A COOKIELESS DOMAIN
Serving static resources from a cookieless domain reduces the total size of requests made for a page. Caveat below!
Enable proxy caching.
Don't serve early loaded external JS files from the cookieless domain.
And use cookie-less domains for static content:
Akamai FEO automation automatically creates cookie-less shards for optimized resources using different domains; the number of shards is configurable.
0.0KB
As listed on:

23. Well-known Best Practices
Minimizing payload size — reducing the size of responses, downloads, and cached pages
437B 1 2
// 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.gecko = true;
1004B
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;}} 3
ENABLE COMPRESSION
Write your web page content to make compression most effective.
Don't use gzip for image or other binary files.
REMOVE UNUSED CSS
Remove any inline style blocks containing CSS that is not used by the current page.
If your site uses external CSS files shared among multiple pages, consider splitting them into smaller files containing rules for specific pages.
If a page references style rules that are not needed right at startup, put them in a separate .css file and defer loading of the file until the onload event is fired.
If you use JavaScript to generate styles, be sure that those functions aren't called from pages that don't use those styles. This may require some refactoring of JS code.
MINIFY JAVASCRIPT
Compacting JavaScript code can save many bytes of data and speed up downloading, parsing, and execution time.
MINIFY CSS
Compacting CSS code can save many bytes of data and speed up downloading, parsing, and execution time.
MINIFY HTML
Compacting HTML code, including any inline JavaScript and CSS contained in it, can save many bytes of data and speed up downloading, parsing, and execution time.
DEFER LOADING OF JAVASCRIPT
Deferring loading of JavaScript functions that are not called at startup reduces the initial download size, allowing other resources to be downloaded in parallel, and speeding up execution and rendering time. See earlier examples. For any file containing more than 25 uncalled functions, move all of those functions to a separate, external JS file. This may require some refactoring of your code to work around dependencies between files. (For files containing fewer than 25 uncalled functions, it's not worth the effort of refactoring.). Common method:
Insert a JavaScript event listener in the head of the containing document that forces the external file to be loaded after the onload event. You can do this by any of the usual scripting means, but we recommend a very simple scripted DOM element (to avoid cross-browser and same-domain policy issues).
OPTIMIZE IMAGES
Choose an appropriate image file format. The type of an image can have a drastic impact on the file size. Use these guidelines:
PNGs are almost always superior to GIFs and are usually the best choice. IE 4.0b1+, Mac IE 5.0+, Opera and Netscape as well as all versions of Safari and Firefox fully support PNG, including transparency. IE versions 4 to 6 don't support alpha channel transparency (partial transparency) but they support 256-color-or-less PNGs with 1-bit transparency (the same that is supported for GIFs). IE 7 and 8 support alpha transparent PNGs except when an alpha opacity filter is applied to the element. You can generate or convert suitable PNGs with GIMP by using "Indexed" rather than "RGB" mode. If you must maintain compatibility with 3.x-level browsers, serve an alternate GIF to those browsers.
Use GIFs for very small or simple graphics (e.g. less than 10x10 pixels, or a color palette of less than 3 colors) and for images which contain animation. If you think an image might compress better as a GIF, try it as a PNG and a GIF and pick the smaller.
Use JPGs for all photographic-style images.
Do not use BMPs or TIFFs.
SERVE SCALED IMAGES
Properly sizing images can save many bytes of data. Plot summary: “…if you serve an image that is larger than the dimensions used in all of the markup instances, you are sending unnecessary bytes over the wire.” Also, consider progressive JPEGs (not called out explicitly by Google Page Speed, but WebPageTest.org will show how much benefit is expected).
SERVE RESOURCES FROM A CONSISTENT URL
It's important to serve a resource from a unique URL, to eliminate duplicate download bytes and additional RTTs. If you have a file named “style1.css” and you use domain sharding, make sure only one domain is used for this resource.
Minification is part of Akamai FEO’s most basic CSS and JS optimizations, which also include automated versioning, fingerprinted filenames and sharding.
494B
235B
Example minified script:
As listed on:

24. Well-known Best Practices
Optimizing browser rendering — improving the browser's layout of a page. First, some details on CSS selectors.
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
Important Note! We won’t fix bad CSS… This one’s on your developers!
USE EFFICIENT CSS SELECTORS
Avoiding inefficient key selectors that match large numbers of elements can speed up page rendering. As the browser parses HTML, it constructs an internal document tree representing all the elements to be displayed. It then matches elements to styles specified in various stylesheets, according to the standard CSS cascade, inheritance, and ordering rules. In Mozilla's implementation (and probably others as well), for each element, the CSS engine searches through style rules to find a match. The engine evaluates each rule from right to left, starting from the rightmost selector (called the "key") and moving through each selector until it finds a match or discards the rule. (The "selector" is the document element to which the rule should apply.)
The following categories of rules are considered to be inefficient:
Rules with descendant selectors
Rules with the universal selector as the key (e.g. – “body * {...}”)
Rules with a tag selector as the key (e.g. – “ul li a {...}” and “* html #atticPromo ul li a {...}”)
Rules with child or adjacent selectors
Rules with the universal selector as the key (e.g. – “body > * {...}” and “.hide-scrollbars > * {...}”)
Rules with a tag selector as the key (e.g. – “ul > li > a {...}” and “#footer > h3 {...}”)
Rules with overly qualified selectors (“ul#top_blue_nav {...}”) - ID selectors are unique by definition. Including tag or class qualifiers just adds redundant information that needs to be evaluated needlessly.
Rules that apply the :hover pseudo-selector to non-link elements (e.g. – “h3:hover {...}”) - The :hover pseudo-selector on non-anchor elements is known to make IE7 and IE8 slow in some cases (
AVOID CSS EXPRESSIONS
CSS expressions degrade rendering performance; replacing them with alternatives will improve browser rendering for IE users.
PUT CSS IN THE DOCUMENT HEAD
SPECIFY IMAGE DIMENSIONS
SPECIFY A CHARACTER SET
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)
As listed on:

25. Well-known Best Practices
Optimizing browser rendering – cont’d
Avoid CSS Expressions (deprecated), put CSS in the document head, using the <link> and <style> tags, and don't
Specify image dimensions in the <img> (and/or <table> and <td>) element or block-level parent, and use dimensions that match those of the actual images (e.g. - don’t 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!
Akamai FEO tools will automatically references into <link> elements.
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.
As listed on:

26. Well-known Best Practices
Optimizing for mobile — tuning a site for the characteristics of mobile networks and mobile devices
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 redirect without any “Vary” header but where Akamai’s 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.
Akamai FEO automation intelligently detects script behaviors that modify the page, and those script resources will not be deferred/async’d.
As listed on:

27. Using a CDN – Practical Considerations

28. 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.
Put here the URLs of the external refs

29. 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)
Put here the URLs of the external refs

30. Using a CDN – What you need to know
Consider things that really help your CDN partners during site design:
Don’t 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: don’t use relative paths that reference ancestor directories (e.g. – “/../../styles.css”); at least Akamai servers won’t pre-fetch those
Put here the URLs of the external refs

31. Consolidating content for desktop & mobile
Case Study 1
Consolidating content for desktop & mobile
The case studies we are going to see in a moment are real cases of Akamai customers were people in our group were involved on the implementation details. For this presentation we will name them yoursite.com

32. Case Study 1: Desktop/Mobile consolidation
Challenge:
Customer wants to consolidate desktop ( 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
Challenge: Let’s say YourSite.com has a mobile site and a desktop site and is interested on consolidating both by implementing Responsive Web Design (RWD) with Server-Side components (RESS) in order to provide optimized content for different devices without the added page load associated with standard RWD practices.
Customer estimated at least 6 months needed to implement server side components and device detection engine, plus added costs associated with extending infrastructure on the origin side needed for this solution.

33. Case Study 1: consolidating desktop and mobile sites
Case Study 1: consolidating desktop and mobile sites. Existing infrastructure
Server
3rd party Mobile detection engine
[desktop site]
300ms
Origin Redirect to m.yoursite.com/index.html
300ms
m.yoursite.com Server
yoursite.com/index.html or

34. 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%

35. Case Study 1: consolidating desktop and mobile sites solution 1
Server
3rd party Mobile detection engine
[desktop site]
50ms
Edge Redirect to m.yoursite.com/index.html
100ms
m.yoursite.com Server
Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname
yoursite.com/index.html or

36. 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)

37. Case Study 1: consolidating desktop and mobile sites solution 2 (content not cached)
Server
3rd party Mobile detection engine
[desktop version cache-key]
Edge server detects desktop browser and pulls content from www origin server
50ms
100ms
Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname
m.yoursite.com Server
[mobile version cache-key]

38. Case Study 1: consolidating desktop and mobile sites solution 2 (content cached)
Server
3rd party Mobile detection engine
[desktop version cache-key]
Edge server detects desktop browser and pulls content from www origin server
100ms
Edge server detects mobile device and pulls content from mobile origin server but delivers under www hostname
m.yoursite.com Server
[mobile version cache-key]

39. 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 Akamai’s 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 server’s 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

40. Case Study 1: consolidating desktop and mobile sites solution 3 (single origin)
Server
[desktop version cache-key]
3rd party Mobile detection engine
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
[mobile version cache-key]

41. Case Study 2
Offline Origin Server

42. 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)

43. 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.

44. Case Study 2: Offline origin server
Origin Crawl
A cron job creates a complete content archive 1
End user 4
Content is Served and Cached
End User Requests a Resource 3
NetStorage
Origin
Content is Uploaded and Expanded
Allows for direct updates to files in place 2 44

45. Designing CDN-Friendly Sites
Case Study 3
Designing CDN-Friendly Sites

46. 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.

47. 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 don’t have to consider these types of optimizations during development.

48. Q&A

49. QR codes
Feedback survey
Follow us on Twitter

50. [Optional]
Trick for handling traffic peaks without updating configuration settings

51. 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 can’t 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

52. 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 for more details

53. Q&A