Advanced Caching Concepts and Optimization Techniques

©2015 AKAMAI | FASTER FORWARDTM
ADVANCED
CACHING
CONCEPTS
Paul Calvano @paulcalvano
Rakesh Chaudhary @nutboltfilms

<Insert Uber Video>
● Courtesy “Late Show With Stephen Colbert”
Travis Kalanick, Uber CEO @ The Late Show with Stephen Colbert

“Anticipatory Delivery”
According to the patent, the packages could wait at the shipper’s hubs
or on trucks until an order arrives.

Caching is a demand-based
distribution optimization to improve
performance and scalability of a
system.

“40% MOBILE USERS WILL ABANDON IF PAGE LOAD >3s”
Meanwhile…
Source: Tammy Everts,
SOASTAhttp://blog.radware.com/
applicationdelivery/applicationacc
elerationoptimization/2015/02/wh
y-you-should-care-about-mobile-
web-performance/

Source: Colin Bendell, Akamai
“Convince your CFO that #perfmatters”
@ Velocity SC 2015
http://goo.gl/eMqNog
“PERFORMANCE CAN MAKE HAPPY USERS…
…AND BUSINESS SENSE”
CBC Case Study
(FIFA World Cup 2014)
 45% spike in traffic
 30% faster
 90-95% offload
 REDUCED #servers
@origin

STEVE SOUDER’S 14 RULES FOR FASTER WEBSITES
Rule 1 - Make Fewer HTTP Requests
Rule 2 - Use a Content Delivery Network
Rule 3 - Add an Expires Header
Rule 4 - Gzip Components
Rule 5 - Put Stylesheets at the Top
Rule 6 - Put Scripts at the Bottom
Rule 7 - Avoid CSS Expressions
Rule 8 - Make JavaScript and CSS External
Rule 9 - Reduce DNS Lookups
Rule 10 - Minify JavaScript
Rule 11 - Avoid Redirects
Rule 12 - Remove Duplicate Scripts
Rule 13 - Configure ETags
Rule 14 - Make AJAX Cacheable

Run a WebPagetest for your (or a favorite) site.
Use the private instance at
http://wpt.advancedcaching.org
Hang onto the results…
EXERCISE

THE THREE
GUIDING
PRINCIPLES OF
CACHING

#1 CACHE AS MUCH AS YOU CAN
*Source: HTTP Archive on Sept 15 2015
97% resources on a page potentially cacheable
However…

Can you see this poll?
i. Yes
ii. No
*POLL

Earlier, you ran a WebPagetest* for your (or a
favorite) site.
What rating did you get for “Cache Static Content”?
i.A
ii.B
iii.C
iv.D
v.F
*POLL
* Use the private instance at http://wpt.advancedcaching.org

#2 CACHE AS LONG AS YOU CAN
*Source: HTTP Archive on Sept 15 2015
In majority of cases,
we notice resource
age much higher than
cache TTL directive
*

#3 CACHE AS CLOSE TO USER AS YOU CAN
Source: Ilya Grigorik, http://chimera.labs.oreilly.com/books/1230000000545/ch01.html#SPEED_FEATURE
“We need to reduce round trips, move the data closer to the client, hide the
latency through caching…”
“Latency
impedes
bandwidth
utilization”

[From earlier WebPagetest result:]
What rating did you get for “Effective Use of CDN”?
i. A
ii. B
iii. C
iv. D
v. F
*POLL

1. Cache as much as you can
2. Cache as long as you can
3. Cache as close to user as
you can

INTRODUCTION
CACHING 101
CACHING 201
CACHING OPTIMIZATION WALKTHROUGH
SCENARIOS & GUIDELINES
Q & A
BREAK
INVALIDATION & PURGING

WHERE CACHING HAPPENS
CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER
GATEWAY

WHAT CONTROLS DO YOU HAVE?
CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER
GATEWAY
HTTP headers for browser cache
Programmatic for localStorage
(and ServiceWorker)
HTTP headers
HTTP headers
CDN Config [ UI / API ]
HTTP headers
Reverse Proxy Config [ UI / API ]

CACHES WE WILL FOCUS ON
1
2
3
4
CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER

CACHE HIT RATIO
COMMON TERMINOLOGY
{#requests from cache} / {#total requests}
CACHE MISS cache query results in object not in cache or stale
STALE RESOURCE object has already expired, need to contact origin
INVALIDATION remove content from cache ahead of expiry
CONDITIONAL GET request resource only if modified

CACHE-CONTROL
BASIC HTTP RESPONSE HEADERS
TTL and other directives
EXPIRES Date/time stamp of future expiry
ETAG Unique resource identifier
LAST-MODIFIED Date/time stamp last modified at server
VARY Add additional request parameters to cache key

CACHE-CONTROL
IMPORTANT HTTP CACHE DIRECTIVES
MAX-AGE Time-to-live delta
NO-STORE
PRIVATE
MUST-REVALIDATE
Do not cache
Meant to be cached only by single user, i.e. browser, not proxy
Do not serve stale
PUBLIC Can be cached by shared proxy

TYPICAL CACHE INTERACTION (LAST-MODIFIED)
CLIENT SERVER
GET
200 OK
Cache-control: <max-age>
Expires: <date-time-stamp>
Last-Modified: <date-time-stamp>
GET
If-modified-since: <last_modified_value>
200 OK or 304 Not Modified
EXPIRES IN
CACHE

TYPICAL CACHE INTERACTION (ETAG)
CLIENT SERVER
GET
200 OK
Cache-Control: <max-age>
Expires: <date-time-stamp>
Etag: “<string>”
GET
If-none-match: “<etag_value>”
200 OK or 304 Not Modified
EXPIRES IN
CACHE • Etags are often mis-configured,
lead to cache pollution
• Rely on Last-modified when you
can
• Useful when caching dynamic
content, e.g. API responses

CACHE KEYS
HOST PATH QUERY ARGUMENTS/ ?
By default, a web cache uses the following combination as primary key:
Example – following represent different cached entities:
www.example.com/en/logo.jpg
www.example.com/jp/logo.jpg
www.example.com/en/logo.jpg?len=100&height=100
www.example.com/en/logo.jpg?len=100&height=200
www.example.com/en/logo.jpg?len=100

Which of the following HTTP status code is *not*
cacheable by default?
i. 404 Not Found
ii. 301 Moved permanently
iii. 200 OK
iv. 302 Found
v. 501 Not Implemented
*POLL

HOW TO DETERMINE TTL?
Content Sensitivity Level CDN TTL Browser TTL
None 7-30 days 2X median user session
Low 12-24 hours 30 min or less
Medium 15 min – 1 hour 10 min or less
High 30 sec – 15 min 0 sec
• If versioning assets, cache for VERY LONG time at CDN/browser
• Otherwise:

DUAL ENEMIES OF CACHE HIT RATE
CACHE POLLUTION
Different entries stored with same keyNeeded content evicted by excessive
un-popular (potentially duplicate)
entries
CACHE COLLISION

AVOID CACHE POLLUTION - TIPS
HOST PATH height=600px/ ?Ignore Redundant Query
Parameter
width=800px utm_source=duck& &1
HOST PATH height=600px/ ?Re-order Query Parameters
Alphabetically
width=800px&
height=600pxwidth=800px
2
★ Rationalize across
fragmented developer
base
Implement at CDN or origin reverse proxy:
3
Ignore Vary headers if
possible. Instead, negotiate
using custom logic
Set downstream Cache-
control: private to avoid
pollution at proxy
Vary: User-agent
Vary: Referer

AVOID CACHE COLLISIONS – RESS EXAMPLE
ORIGIN
CDN
MOBILE USER
DESKTOP USER
version
version
Desktop content removed
Mobile content removed
SAME
URL
• Server conditionally assembles :: CDN conditionally caches
• Device family string inserted into cache key: e.g. [android|iphone|ipad|desktop]
• Set downstream
• Vary: User-agent (to comply with SEO)
• Cache-control: private to prevent caching on proxies

HTTP POST CACHING
POST /search HTTP/1.1
content-type: application/json
host: https://www.example.com
content-length: 47
{“Action”:“Search”,“Query”:“shirts”,“Pag
e”:“1”}
www.example.com search ed7fcd94e1f742ecf8573b622ded65cc/ ?
★ Use only for idempotent requests
★ Be careful with request size
★ Be cautious with PII data!
Construct the appropriate cache key...

PRE-FETCH / PRE-FRESH
Prebrowsing -
http://www.stevesouders.com/blog
/2013/11/07/prebrowsing/
• Pre-fetch
• Fetch object before client needs it
• Can be used at browser (<link rel=“prefetch”…) and CDN
• Prefresh
• Re-validate asynchronously before cache expires
• Can be used at browser (stale-while-revalidate, IE pre-check/post-check) and CDN

CACHING PROTECTED CONTENT
CDN
AUTH
SERVER
STORAGE
SERVER
1
6
3
2
4
5
1. USER REQUEST
2. AUTH REQUEST (HEAD)
3. AUTH RESPONSE
4. CONTENT REQUEST (ON MISS)
5. CONTENT RESPONSE (ON MISS)
6. USER RESPONSE
USER
★ Ensure must-revalidate is ON
★ Great for large file downloads
? What if auth server doesn’t support HEAD?

CACHING DYNAMIC PAGES
Cache-able:
Until this happens…
Solution:
• Serve from cache for non-
logged in users
• Bypass cache for logged in
users
• Use cookies to determine
state
(Much more to come in next section)

OFFLOADING REDIRECTS
CDN
• Implement
redirects at edge if
possible
• Use appropriate
status codes: 301
or 302

OFFLOADING REDIRECTS AVOIDS THIS…
m-dot redirect
implemented in
javascript!?!

HTML5 localStorage
• Dedicated and robust client side storage
• 5MB dedicated per domain
• Scriptable, allows get/put/remove commands
• Useful in FEO optimizations
• e.g. decoupling JavaScript download from
execution
…Stay tuned for ServiceWorker

The fastest request is
the one you don’t have to make.

OPTIONS FOR UPDATING CACHE
1
2
3
RELY ON TTL
INVALIDATE
PURGE
elegance, safety
control, risk to origin

RELY ON TTL
1
BROWSER EDGE ORIGIN
GET
GET
200 OK with cache directives*
200 OK with cache directives
CONDITIONAL GET
200 OK (new object)
2
EXPIRES IN
BROSWER CACHE
CONTITIONAL GET
200 OK (new object)
EXPIRES IN
EDGE CACHE
* Cache directives:
cache-control
expires
last-modified
etag
OBJECT
MODIFIED
• Timestamp determined at time of caching via HTTP response
• Offers graceful mechanism to retire stale content
• Works on browsers, CDN and proxies

INVALIDATING
INVALIDATE
1
BROWSER EDGE ORIGIN
GET
GET
CONDITIONAL GET
200 OK
2
EXPIRES IN
BROSWER CACHE
CONDITIONAL GET
200 OK*
OBJECT MARKED
AS EXPIRED
OBJECT
MODIFIED
* Since object modified
• Instruct cache to expire content but leave it in cache

INVALIDATING (CONTD.)
INVALIDATE
1
BROWSER EDGE ORIGIN
GET
GET
CONDITIONAL GET
2
EXPIRES IN
BROSWER CACHE
CONDITIONAL GET
304 NOT MODIFIED OK*
OBJECT MARKED
AS EXPIRED
* Since object
not touched
• Works for CDN/proxies, not browsers
• Most CDNs provide both UI and API
304 NOT MODIFIED OK*

PURGING
PURGE
1
BROWSER EDGE ORIGIN
GET
GET
200 OK with cache directives*
CONDITIONAL GET
200 OK
2
EXPIRES IN
BROSWER CACHE
[FULL] GET
[ALWAYS] 200 OK
OBJECT REMOVED
FROM CACHE
• Instruct cache to remove content
• Works for CDN/proxies, not browsers
• Most CDNs provide both UI and API

Daily drop in % offload coincides with a spike in HTTP 3xx responses due to daily cache invalidations
REQUEST SPIKES DUE TO INVALIDATION/PURGE EVENTS

RECOMMENDATIONS
GOOD
BETTER
BEST Version assets and use very large TTLs
Use TTLs apropos publishing needs
Allow serving stale
CDN TTL > Browser TTL for better control
Execute invalidation/purge at non-peak times

 LAMP Stack running on a single Amazon EC2
East instance.
 Magento application layer, with “Madison
Island” sample theme.
 No CDN, No Browser Caching, No Origin
Cache.
 This will be our starting point…
DEMO APPLICATION
http://www.advancedcaching.org

INITIAL PERFORMANCE SNAPSHOT
• Distance impacts performance.
• VA->NY 2X faster than VA->CA
CALIFORNIA
NEW YORK

PERFORMANCE IMPACT OF LATENCY

BROWSER CACHING ISSUES

BUT REPEAT VIEW SHOWS BROWSER CACHING…

BROWSER CACHING GONE WRONG?
Embedded content missing Cache-Control headers!

UNPREDICTABLE BROWSER CACHING
From http://httpwg.github.io/specs/rfc7234.html#heuristic.freshness
• "A cache may assign a heuristic expiration time when an explicit time is not
specified…”
• "If the response has a Last-Modified header field, caches are encouraged to use a
heuristic expiration value that is no more than some fraction of the interval since that
time (typically 10%)”.
★ Both Firefox and Chrome have
implemented the heuristic
freshness guidelines

EXAMINING BROWSER CACHEABILITY OF RESOURCES
FIREFOX
about:cache

EXAMINING BROWSER CACHEABILITY OF RESOURCES
http://redbot.org/

1. Edit Apache httpd.conf and add a Directive to set Cache-Control Headers
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "now"
ExpiresByType image/gif "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType text/css "access plus 30 days"
ExpiresByType text/javascript "access plus 30 days"
ExpiresByType application/x-javascript "access plus 30 days"
</IfModule>
2. Restart Apache
3. Test to confirm it worked.
CONFIGURING CACHE-CONTROL AND EXPIRES HEADERS

BEFORE / AFTER

CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER

1. Setup basic configuration on CDN
2. Configure cache TTLs on CDN
3. Define behaviors for un-cacheable content
4. Test site via CDN
5. Configure DNS to route traffic through CDN
BASIC CDN SETUP

BASIC CDN SETUP: CONFIGURE HOST AND ORIGIN

BASIC CDN SETUP: CONFIGURE HOST AND ORIGIN
IF INCOMING_HOST == “www.advancedcaching.org”
THEN
Set ORIGIN ADDRESS = “ec2-54-154-215-217.compute-
1.amazonaws.com”
Set ORIGIN PORT = “80”
Set FORWARD HOSTNAME = $INCOMING_HOST
Set CACHE_KEY_HOSTNAME = $INCOMING_HOST
Support gzip

BASIC CDN SETUP: CACHING RULES
IF ( FILE_EXTENSION == <list of cacheable extensions> )
THEN
a) Set CDN Cache TTL to 30 days
b) Allow content to be served stale if unable to validate
c) Set downstream Cache-Control & Expires
Lifetime = smaller of (origin header | remaining edge TTL)
ELSE IF ( NOT_CACHEABLE )
THEN
a) No-Store at CDN
b) Pass downstream cacheability headers from origin

BASIC CDN SETUP: TESTING
1. Confirm traffic is
routing through CDN
and cacheable content
is Cached
2. Configure hosts file to route traffic
through CDN
3. Test and verify site works as expected

BASIC CDN SETUP: UPDATING DNS TO GO LIVE

CONFIRMING CDN CACHE HITS
http://wpt.advancedcaching.org/
• WebPageTest Private Instance w/ some modifications:
1. Extends Details tab Reports to include Cacheability Data
2. New Cache-Analysis tab for correlating Last-Modified w/ CDN
Cache TTLs and Cache-Control/Expires headers
3. Automatically injects Akamai diagnostic headers

CONFIRMING CDN CACHE HITS

PERFORMANCE IMPACT OF CDN
 Faster load times
 Page renders faster since edge server close to end user
AKAMAI
ORIGIN

IMPROVING OFFLOAD VIA CDN
TIERED DISTRIBUTION
Parent / child caches to maximize offload
PRE-FETCH CONTENT
Offload milliseconds before content requested
PRE-FRESH CONTENT
Update cached content before TTL expires

ADVANTAGES OF TIERED DISTRIBUTION

• How old are the objects?
• How long do browsers cache (cache-
control)
• What do we know about publishing
process, i.e. versioned assets,
schedules, etc.?
DETERMINING APPROPRIATE CACHE TTLS?

• For versioned assets, TTL should
be very high.
• For non-versioned assets, TTL for
CDN should be higher than
browser TTL
• Consider what needs to happen
when content is modified
MANAGING CDN + BROWSER CACHING

Using http://wpt.advancedcaching.org, run a WebPagetest
Measurement and view the Cache Analysis Section.
Do you see any opportunities to improve your caching
strategy?
i. Yes
ii. No
iii. Not Sure
*POLL

CACHING AT THE ORIGIN

VARNISH CONFIGURATION
backend default {
.host = "54.152.215.217";
.port = "80";
.connect_timeout = 1s;
.first_byte_timeout = 5s;
.between_bytes_timeout = 2s;
}
sub vcl_recv {
if (req.url ~ ".(png|gif|jpg|swf|css|js)$") {
unset req.http.cookie;
}
}
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.Varnish-X-Cache = "HIT";
} else {
set resp.http.Varnish-X-Cache = "MISS";
}
}
/etc/varnish/default.vcl
DAEMON_OPTS="-a :80
-T localhost:6082
-f /etc/varnish/default.vcl
-S /etc/varnish/secret
-s malloc,256m"
/etc/default/varnish

UPDATE CDN SETUP: CHANGE ORIGIN
IF INCOMING_HOST == “www.advancedcaching.org”
THEN
Set ORIGIN ADDRESS = “54.152.215.217”
Set ORIGIN ADDRESS = “52.91.239.172”
Set ORIGIN PORT = “80”
Set FORWARD HOSTNAME = $INCOMING_HOST
Set CACHE_KEY_HOSTNAME = $INCOMING_HOST
Support gzip

ORIGIN CACHE - TESTING
First test directly via
origin cache (bypass
CDN)
Confirm requests are
offloaded

ORIGIN CACHE – TESTING VIA CDN

CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER
But wait, there is more…

DYNAMIC PAGE TYPES
1 - UNCONDITIONALLY CACHEABLE
2 - CONDITIONALLY CACHEABLE
3 – CACHEABLE WITH MULTIPLE VARIATIONS
4 – NON-CACHEABLE

Page is the same for all users.
• Example: Completely Static HTML
• This can be cached like any embedded
object, e.g. image
#1 UNCONDITIONALLY CACHEABLE PAGE

Page is the same for all users, expect for
certain conditions.
• Example: homepage with mini cart
coded in the HTML
• This may be conditionally cached for
some users, e.g. for un-signed user
#2 CONDITIONALLY CACHEABLE PAGE

Page is conditionally or unconditionally
cacheable, but requires multiple version
to be cached.
• Example: homepage with multiple
languages depending on the user’s
context
• Cache key modifications need to be
made
#3 DYNAMIC PAGE WITH MULTIPLE VARIATIONS

Page is completely personalized,
unique per request – can not be
cached.
#4 NON-CACHEABLE PAGE

Do you leverage any techniques for caching dynamic pages?
i. Yes
ii. No
*POLL

(If you don’t cache dynamic pages), why not?
i. Our pages are too dynamic
ii. We could, but chose not to
*POLL

Is anything different returned for 2 identical
requests?
$ diff -s <(curl -Lvs http://www.advancedcaching.org/ 2>&1) <(curl -Lvs
http://www.advancedcaching.org/ 2>&1)
< < Set-Cookie: frontend=uim2n3k6atbis4slovn9r5dpc1; expires=Sun, 04-Oct-2015 06:34:28
GMT; Max-Age=3600; path=/; domain=www.advancedcaching.org; HttpOnly
---
> < Set-Cookie: frontend=dnjvcbvt9bsei7q1vhnfo68o81; expires=Sun, 04-Oct-2015 06:34:28
GMT; Max-Age=3600; path=/; domain=www.advancedcaching.org; HttpOnly
TESTING DYNAMIC CONTENT FOR CACHEABILITY
★ Set-Cookie doesn’t impact our ability to
cache dynamic HTML, provided the cache
strips Set-Cookie from the response.

Where is the welcome message coming from?

Where is the mini shopping cart coming from?

Is there anything in the request indicating this is a logged in visitor
with an item in their cart?
Conclusion: The page is cacheable, but we don’t have enough
information to determine it’s cacheability.

Cache part of the page
Add indicators to conditionally cache
Rewrite page to leverage Ajax/JSON for dynamic portions
DEALING WITH NON-CACHEABLE DYNAMIC PAGES
GOOD
BETTER
BEST

1. Cache the HTML <head> section of
response at edge
2. Serve that while origin is generating
rest of HTML
3. Serve the rest of the HTML once it
is received
ACCELERATING DYNAMIC PAGES - AKAMAI EDGESTART
★ This technique will accelerate
render time, but provides no
origin offload.

• Set a “LoggedIn” cookie to indicate when user logs in, and a
“ContentsInCart” cookie when a user adds an item to their cart.
• This can be done at origin or at CDN
• Cache page conditionally based on the cookie indicators
• If request contains “LoggedIn=true” or “ContentsInCart=true” cookie,
bypass cache and forward request to origin
• Else serve response from cache
CACHING DYNAMIC HTML

Add To Cart operation:
./apps/magento/htdocs/app/code/core/Mage/Checkout/controllers/CartController.php
Login operation:
./apps/magento/htdocs/app/code/core/Mage/Customer/controllers/AccountController.php
UPDATING OUR DEMO APP
setcookie("ContentsInCart", "true", time()+3600, "/", "www.advancedcaching.org");
setcookie("LoggedIn", "true", time()+3600, "/", "www.advancedcaching.org");

CACHING DYNAMIC CONTENT CONDITIONALLY
IF ( REQUEST_PATH == “/” OR “/akamai-polo.html” )
AND ( REQUEST_COOKIE “ContentsInCart” != “true” )
AND ( REQUEST_COOKIE “LoggedIn” != “true” )
THEN
a) Set CDN Cache TTL to 1 day
Lifetime = smaller of (origin header | remaining edge TTL

WIDENING THE NET...
IF ( FILE_EXT == html)
AND ( REQUEST_PATH NOT (/checkout/* OR /account/* )
AND ( REQUEST_COOKIE “ContentsInCart” != “true” )
AND ( REQUEST_COOKIE “LoggedIn” != “true” )
THEN
a) Set CDN Cache TTL to 1 day
★ The ability to serve stale if unable to
validate is extremely useful for dynamic
content, especially if the origin is under
stress or experiencing issues.

CACHING SEARCH RESULTS
http://www.advancedcaching.org/catalogsearch/result/?q=casual
★ When caching content such as this, there is
a potential for cache pollution. Creating
separate cache buckets for this content can
mitigate the risk.

OFFLOADING 3RD PARTY CONTENT
3rd party fonts are a SPOF, but
required to render this page
2 additional DNS lookups + 3 TCP
connections for loading content
critical to the render path

HTML:
CSS:

Serve fonts on the primary domain when possible
• Requires code change at origin
Rewrite HTML and perform forward re-writes at CDN to
3rd Party:
• Requires no code changes at origin
• Replace 3rd party hostnames from HTML & CSS
• @CDN, match on filenames, fetch from alternative origin
• Cache response at CDN
GOOD
BEST

ORIGINAL HTML / CSS FOR FONTS
HTML:
CSS:

HTML FIND / REPLACE
IF ( PATH CONTAINS “/” ) OR ( FILE_EXTENSION == “php” )
THEN
a) Find “fonts.googleapis.com”
b) Replace with
“www.advancedcaching.org/googleapis/fonts.googleapis.com”
IF ( PATH CONTAINS “/googlapis/fonts.googleapis.com” )
THEN
a) Find “fonts.gstatic.com”
b) Replace with
“www.advancedcaching.org/gstatic/fonts.gstatic.com”

REWRITTEN HTML / CSS FOR FONTS
HTML:
CSS:

FORWARD REWRITE RULE + CACHING
IF ( PATH CONTAINS “/googleapis/” )
THEN
a) Remove /googleapis/ from the URL
b) Change the origin server to fonts.googleapis.com
c) Set CDN Cache TTL to 7 days
d) Allow content to be served stale if unable to validate
e) Set downstream Cache-Control & Expires

FORWARD REWRITE RULE + CACHING
IF ( PATH CONTAINS “/gstatic/” )
THEN
a) Remove /gstatic/ from the URL
b) Change the origin server to fonts.gstatic.com
c) Set CDN Cache TTL to 7 days
d) Allow content to be served stale if unable to validate
e) Set downstream Cache-Control & Expires

OFFLOADING 3RD PARTY CONTENT - RESULTS
BEFORE
- Request #14.
- DNS Lookup and TCP
connection for single request
- Start render at 0.9s
AFTER
- Request #4.
- Render blocking CSS request prioritized by
browser
- No additional DNS overhead
- TCP connection reused
- Request is cached at the edge
- Start render at 0.7s

OFFLOADING 3RD PARTY CONTENT - RESULTS
Accelerating resource critical render path will result in faster render time
Offloading resource at edge and allowing it to be served stale eliminates the risk of SPOF
3rd PARTY CACHING ON
3rd PARTY CACHING OFF

CACHE PARENT
CACHE CHILD
ORIGI
N
CDN
BROWSER
“Very Nice!”

Performance Under Load
ALL CACHING ON
NO CACHING
ALL CACHING ON
NO CACHING

E-COMMERCE APPLICATION SCENARIO

• Proactively increase the capacity of J.Crew’s web
applications
• Need to support traffic surges due to media events
• Maximize performance for repeat visitors
THE NEED FOR MAXIMIZING OFFLOAD

CACHING DYNAMIC PAGES @ J. CREW
SINCE 2009!
REDIRECTS CONFIGURED AT CDN LAYER
SPLIT ORIGIN FOR DESKTOP AND MOBILE TRAFFIC
FLEXIBLE CACHE KEYS TO MAXIMIZE OFFLOAD

REDIRECTS CONFIGURED AT THE CDN
• Redirects can not be cached, but can be moved closer to the user
• Configuring redirects at the CDN layer eliminates need for extra
round trip to the origin
• Redirects are location based

SAME URL, DIFFERENT ORIGINS. BOTH CACHED
Flexible cache keys enabled multiple variations of the page to be cached,
including multiple origins

… while maintaining high offload and reducing costly traffic at origin.
SHORT TTLS FOR DYNAMIC PAGES ENSURES FRESHNESS

… maximizes offload and improves load time for repeat visitors
LONG TTLS FOR STATIC CONTENT…

HIGH TRAFFIC EVENT SCENARIO

ANATOMY OF A FLASH CROWD

1. Cache as much of page as possible
2. Limit 3rd party content to reliable providers
3. Limit Ajax calls that are un-cacheable
4. Failover strategy: retry on error, serve custom error page with
auto-refresh
5. CDN hosted waiting room for controlling origin load
CACHING TECHNIQUES TO MITIGATE FLASH CROWDS

CACHING TECHNIQUES TO MITIGATE FLASH CROWDS

MOBILE APPLICATION SCENARIO

APP
APIs

• API provider -> Partner/Developer -> User
• Others dictate release schedules
• Risk of rogue implementations
• Once spec’d, hard to update
BEHOLDEN TO PARTNERS & DEVELOPERS

• Could originate from anywhere!
• Big spikes possible
• Hard to predict partner adoption
rates
HIGHLY UNPREDICTABLE TRAFFIC

Slow devices over slow connections
APPS DOMINATE MOBILE EXPERIENCE

• Start with compute cloud
• Complement with CDN to address
performance, scale and security needs
• Address total cost of ownership
1 – EMBRACE THE CLOUD

• Cache dynamic, non-personalized
responses
• Use Etags
• Rationalize URL parameters to avoid
fragmentation - do it on edge or origin
• Enforce uniform ordering of URL
parameters
Same Content, Multiple Keys:
http://example.com/weather-data.asp?slat=47.43&slon=19.27&langid=20
http://example.com/weather-data.asp?langid=20&slat=47.42&slon=19.29
http://example.com/weather-data.asp?langid=20&slat=47.41&slon=19.25
Rationalized:
Rationalize + Re-order
at edge or at origin using 302
2 - MAKE CACHING YOUR FRIEND

• Most apps require entitlement on
every request
• Segregate authorization vs. content
flows
• Consider caching auth response at edge
3 - PROTECT AND PERFORM SIMULTANEOUSLY

• Long TTLs preferred, but short ones will
do
• Enable cache-control & expires headers
for client and gateway proxies
• Implement failover
• Avoid redirects
• yadda, yadda, yadda
4 - USUAL RECOMMENDATIONS APPLY

• Pick up your copy of the preview edition
of the upcoming book -
“High Performance Images”
• Talk to an HTTP/2 expert and view our
demo!
VISIT AKAMAI AT KIOSK #22

REFERENCES

TOOLS WE USED TODAY
Tool URL
WebPageTest http://www.webpagetest.org
WebpageTest Private Instance http://wpt.advancedcaching.org
Google PageSpeed Insights https://developers.google.com/speed/pagespeed/insights/
Keynote KITE http://kite.keynote.com
Soasta http://www.soasta.com
REDbot https://redbot.org/
Charles Proxy http://www.charlesproxy.com/
Chrome DevTools https://developers.google.com/web/tools/setup/workspace/setup-devtools
Akamai {OPEN} API
https://developer.akamai.com/
https://community.akamai.com/community/developer/blog/2015/08/19/getting-
started-with-the-v2-open-ccu-api?sr=stream

ADDITIONAL INFORMATION
Topic Author URL
HTTP 1.1 Caching Specs IETF http://httpwg.github.io/specs/rfc7234.html
A Practical Guide to Web Resource
Caching – Parts 1 & 2 Pierre Lermant, Akamai
https://blogs.akamai.com/2013/11/a-practical-guide-to-web-
resource-caching-part-1.html
https://blogs.akamai.com/2013/11/part-2-a-practical-guide-to-
web-resource-caching.html
Dynamic Content: A Short TTL as an
Alternative to Purge Pierre Lermant, Akamai
https://blogs.akamai.com/2014/12/dynamic-content-a-short-ttl-
as-an-alternative-to-purge.html
Measuring Impact of Page Caching
Akshay Ranganath,
Akamai
https://community.akamai.com/community/web-
performance/blog/2015/08/12/measuring-impact-of-page-caching
Prebrowsing
Steve Souders,
SpeedCurve http://www.stevesouders.com/blog/2013/11/07/prebrowsing/

Thank you!

Advanced Caching Concepts and Optimization Techniques

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Advanced Caching Concepts and Optimization Techniques

Similar a Advanced Caching Concepts and Optimization Techniques (20)

Último

Último (20)

Advanced Caching Concepts and Optimization Techniques