The Need for

Speed

An  Introduc+on  to  Website  Performance  

 Your  Host  Today  is….  
•  Richard  Sheldon  
•  Lead  So8ware  Engineer  (s=ll  cuts  code)  
•  20+  Years  in  So8ware  (really  old  man)  
•  Worked  on  site  with  600+  million  page  views  a  
month  (that  was  fun!)  
•  Currently  working  on  improving  Cobalt  
Websites  performance  and  monitoring  
 Topics  
•  Why  you  should  care  about  website  
performance  
•  Ways  to  measure  and  analyze  website  
performance  
•  How  to  improve  website  performance  
–  Focused  on  Browser  Performance  not  server-­‐side  
scalability  and  performance  
•  The  BaQle:  Features  vs  Performance  
 Ques=on  
Q:  When  you’re  implemen=ng  a  new  product  
feature,  who  is  responsible  for  making  it  
successful?  

Product  Management   Market  Research   Requirement  Analysts  

Developers   Quality  Assurance/Testers  

Opera=ons  
 The  Misconcep=on  
All  too  o8en  performance  is  seen  as  something  
“the  techies  do”,  and  not  as  a  business  Feature.  
 

WRONG!!  
 Someone  who  gets  it…  

"As  a  product  manager  you  should  

know  that  speed  is  product  feature  
number  one."  
Larry  Page,  founder  of  Google  
(quoted  by  Urs  Hölzle  at  Velocity  conference  2010)  
Why  should  you  care?  
Don’t  Believe  Me?  

hQp://www.aberdeen.com/aberdeen-­‐library/5136/RA-­‐performance-­‐web-­‐applica=on.aspx  
 Why?  

hQp://www.strangeloopnetworks.com/assets/images/visualizing_web_performance_poster.jpg  
Web  Stress  –  It’s  REAL!  

hQp://www.strangeloopnetworks.com/assets/images/Infographics/Web-­‐Stress-­‐Infographic-­‐500.jpg  
Time  =  Money:  Examples  

hQp://www.strangeloopnetworks.com/assets/images/visualizing_web_performance_poster.jpg  
Time  =  Money:  Examples  

hQp://www.strangeloopnetworks.com/assets/images/visualizing_web_performance_poster.jpg  
Bounce  Rates  

hQp://www.aberdeen.com/aberdeen-­‐library/5136/RA-­‐performance-­‐web-­‐applica=on.aspx  
Pages  per  Visit  
 Faster  Cats  get  all  the  Cream  
•  Site  Speed  is  a  factor  in  Google’s  page  rank  
•  Higher  in  the  results  page  =  WAY  more  clicks  

hQp://searchenginewatch.com/ar=cle/2215868/53-­‐of-­‐Organic-­‐Search-­‐Clicks-­‐Go-­‐to-­‐First-­‐Link-­‐Study  
 Measuring  Performance  
•  Split  into  
–  Server  side  –  how  long  does  it  take  the  server  to  
generate  a  response  
–  Browser  side  –  how  long  does  it  take  the  browser  
to  render  (draw)  the  page,  including  downloading  
•  CSS  
•  JS  
•  Images  
Browser  Timeline  

hQps://dvcs.w3.org/hg/webperf/raw-­‐file/=p/specs/Naviga=onTiming/Overview.html  
 Measuring  Performance  
•  Naviga=on  start  
–  This  is  the  =me  the  user  begins  a  transac=on  by  clicking  on  a  
link,  submiqng  a  form,  or  entering  a  URL  in  a  browser  
•  Time  to  First  byte  (TTFB,  response  start)  
–  This  is  the  =me  that  the  requested  page  is  received  by  the  
browser  –  (remember  HTTP  responses  may  be  in  chunks).  
•  DOM  ready  (Document  Ready,  DOMContentLoaded  event)  
–   This  is  the  =me  at  which  the  DOM  has  been  loaded  by  parsing  
the  response.  
•  Page  ready  (Window  Load,  loadEventStart)  
–  This  is  the  =me  at  which  the  page  completes  loading  of  the  
main  HTML  and  it’s  inline  assets  
•  Some  assets  may  not  start  loading  un=l  window.load,  as  they’re  
considered  non-­‐urgent  
 The  Waterfall  
•  Most  useful  tool  when  inves=ga=ng  Website  
Performance  
 
 The  Waterfall  
•  Can  be  generated  many  ways  
–  Firebug  (Firefox)  
–  Chrome  Inspector  
–  IE9+  Tools    
–  Safari  Inspector  
–  webpagetest.org  (uses  real  browsers  to  generate)  
•  This  site  is  very,  very  useful!  
 The  Waterfall  
•  Lets  you  see  where  the  =me  is  spent,  and  
allows  you  to  focus  your  op=miza=on  on  that  
•  Usually  server  side  is  only  responsible  for  
10-­‐20%  of  overall  page  load  =me  
–  Very  important,  as  it’s  part  of  the  infrastructure  
YOU  pay  for,  and  must  keep  reliable  
•  Most  of  web  page  op=miza=on  is  focused  
around  what  the  browser  is  doing  
–  We’re  going  to  talk  a  lot  about  this  soon!  
 Scorecards  
•  Analyzes  your  web  page  against  well  knows  
best  prac=ces  
•  Google  Page  Speed  Insights  
•  Yahoo!  YSlow  
•  Both  are  available  for  Firefox  (Firebug)  and  
Chrome,  and  an  online  version  
Scorecards  (YSlow)  
Scorecards  (Page  Speed)  
 Real  User  Monitoring  
•  Problem  with  the  Waterfall  is  that  it’s  on-­‐demand,  one  
page,  one  browser  at  a  =me  
•  Also  want  to  get  a  picture  of  the  overall  performance  ALL  
users  are  experiencing  
•  This  is  known  as  Real  User  Monitoring  (RUM)  
–  Also  “End  User  Monitoring”  (EUM)  
•  Record  metrics  in  browser  (e.g.  via  HTML    Timing  API)  then  
fire  a  pixel  tag  to  send  data  to  a  collec=on  server  (non-­‐
blocking  call)  
•  Can  implement  this  yourself  or  use  a  3rd-­‐party  
–  New  Relic,  Compuware  DynaTrace,  Gomez  Networks  etc  
–  hQp://www.real-­‐user-­‐monitoring.com/the-­‐complete-­‐list-­‐of-­‐
end-­‐user-­‐experience-­‐monitoring-­‐tools/  
 Real  User  Monitoring  
•  Performance  aggregated  over  all  page  views  
 Real  User  Monitoring  
•  Shows  geographical  varia=ons  
 Measure,  Measure,  Measure  
•  Before  you  start  op=miza=on  
–  MEASURE  PERFORMANCE!  
•  Make  small  sets  of  changes  (if  possible)  
–  MEASURE  PERFORMANCE!  
•  Things  never  work  out  quite  as  you  expect  them  
to  
–  The  problem  you  think  you  have  may  not  always  be  
the  root  cause  
•  Small  changes  let  you  change  course  before  you’re  too  
invested  
 Website  Op=miza=on  Techniques  
•  Well  known  “Industry  Best  Prac=ces”  
•  Read  books/blogs  by  Steve  Souders  
–  Was  Chief  Performance  Yahoo!  
–  Now  Web  Performance  Evangelist  at  Google  

hQp://www.stevesouders.com/  
hQp://www.slideshare.net/w3guru/high-­‐performance-­‐websites-­‐by-­‐souders-­‐steve-­‐
presenta=on  
 
Rule  1:  Make  Fewer  HTTP  Requests  
•  Image  Maps  
–  Not  used  much  these  days  
–  Defining  area  coordinates  –  tedious/errors  
•  CSS  Sprites  
–  Specify  image  posi=on  and  size    to  crop  one  image  
out  of  sprite.  Great  for  icons  that  appear  on  many  
pages  
•  Inline  images  
–  src="data:image/gif;base64,R0lGODlhAQ…”!
•  Combine  CSS/JS  files  
–  E.g.  dynamically  concatenate  &  cache  
–  Add  minifica=on!  (see  Rule  10)  
 Rule  2:  Use  a  CDN  
•  A  content  delivery  network  or  content  
distribu=on  network  (CDN)  is  a  large  distributed  
system  of  servers  deployed  in  mul=ple  data  
centers  across  the  Internet  
•  The  goal  of  a  CDN  is  to  serve  content  to  end-­‐
users  with  high  availability  and  high  performance  
•  Close  to  end-­‐users  (browsers),  cached  content  
•  Examples:  Akamai,  Amazon  CloudFront,  
Limelight,  Edgecast  
•  Downside:  Costs  money  (some=mes  lots  of  it)  

Defni=ons  from  Wikipedia  

 Rule  3:  Add  an  Expires  Header  
•  Tells  the  browser,  CDN  and  Proxies  how  long  they  can  keep  
an  asset  (image,  CSS,  JS,  Font)  
•  Ideally  want  indefinite  expires  header  
–  Max  recommended  =me  is  1  year  
–  Must  implement  cache-­‐bus=ng  technique  that  will  change  the  
url  if  the  content  changes  
•  E.g.  version  #  or  hash  on  the  url  
•  hQp://assets.cobaltnitra.com/websites/widgetsv/021306-­‐c621574/widgets/Video/youtube_sprite.png  
•  hQp://assets.cobaltnitra.com/websites/generated/bundles/0e057510333028e4/d986c70071aebc33/wad/
haecagfz80oy9hvi7qq==/bundle.css  

•  Empty  vs  Primed  Cache  

–  Users  will  likely  view  a  page  mul=ple  =me,  and  mul=ple  pages  
with  a  site.  Content  with  far-­‐future  expiry  will  not  need  to  be  
downloaded  again  
•  RESULT:  Much  faster  user  experience  
 Rule  4:  GZIP  Components  
•  Compress  HTML,  CSS  and  JS,  JSON,  XML  
–  Can  save  a  lot  of  bandwidth  
•  Images  and  PDFs  are  inherently  compressed  
•  There  is  a  cost  
–  It  takes  CPU  =me  to  compress/de-­‐compress,  but  
with  today’s  CPUs  it  not  normally  an  issue  
 Rule  5:  Put  CSS  at  the  Top  
•  Browsers  block  rendering  a  web  page  un=l  all  
external  stylesheets  have  been  downloaded  
•  Inline  style  blocks  (specified  with  the  <style>  tag)  
can  cause  reflows  and  shi8ing  of  content  
•  Important  to  put  references  to  external  
stylesheets,  as  well  as  inline  style  blocks,  in  the  
head  of  the  page  
•  By  ensuring  that  stylesheets  are  downloaded  and  
parsed  first,  you  can  allow  the  browser  to  
progressively  render  the  page  

hQps://developers.google.com/speed/docs/best-­‐prac=ces/rendering#PutCSSInHead  
Rule  6:  Put  JS  Scripts  at  the  boQom  
•  Progressive  rendering  is  blocked  for  all  content  below  the  
script  
–  JS  may  modify  the  DOM,  which  affects  rendering  
–  Move  scripts  lower  allows  more  content  to  be  rendered  
progressively  
•  Move  as  much  JS  content  to  the  end  of  the  page  as  possible  
–  Can’t  move  code  that  used  document.write  (EVIL!)  
•  Defer  loading  if  possible  
–  Use  the  async  tag  on  <script>  element  
•  Not  all  browsers  support  it  (IE  8  &  9  don’t)  
–  Dynamically  add  <script>  tag  using  JS  
•  E.g.  at  window.load  
 Rule  7:  Avoid  CSS  Expressions  
•  Used  to  set  CSS  proper=es  Dynamically  
•  Problem:  Expressions  execute  many  =mes  
–  Mouse  move,  key  press,  resize,  scroll  etc  
•  Can  o8en  be  worked  around  by  
–  One-­‐=me  expressions  
•  Where  JS  func=on  referenced  by  the  CSS  expression  
overwrites  the  CSS  value  with  a  non-­‐expression  value  
–  Event  Handler  
•  Change  the  CSS  value  from  a  JS  event  handler  
registered  just  for  the  event  of  interest  (e.g.  scroll)  
 Rule  8:  Make  CSS/JS  External  
•  Main  HTML  content  page  typically  contains  dynamic  content,  which  
prevents  the  page  from  being  cached  
–  E.g.  Personalized  messages  like  “Welcome  Richard”  
•  Inline  JS/CSS  will  get  downloaded  for  every  page  view  
–  Adds  page  weight  
•  Externalize  CSS  and  JS  and  set  far-­‐future  expires  headers  
–  These  will  be  used  for  primed-­‐cache  visits  
–  Far-­‐future  expires  will  allow  CDNs  to  cache  close  to  consumers  
•  Quick  response  =mes  when  files  are  not  in  browser  cache  
•  O8en  good  to  have  a  global  site  file  and  then  page  specific  ones  for  beQer  
caching  
•  Some  websites  will  download  CSS/JS  files  that  may  be  needed  for  pages  
users  are  likely  to  visit  
–  Use  window.onload  handlers  to  dynamically  download  the  files  
–  Can  use  Iframes  
–  Take  care  not  to  block  any  visible  content  on  the  main  page  
 Rule  9:  Reduce  DNS  Lookups  
•  DNS  maps  domain  name  to  IP  Address  
–  Entries  specify  a  =me-­‐to-­‐live  value  (TTL)  
–  Shorter  TTL  allows  faster  failover  (if  your  site  has  other  servers  to  
failover  to!),  at  the  expense  of  frequent  lookups  
–  Typically  20-­‐120ms  
•  OS  and  Browser  both  have  DNS  caches  
–  Browsers  some=mes  ignore  TTL  and  impose  their  own.  
–  Fallback  to  OS  DNS  Cache  
•  Block  Parallel  Downloads  
•  How  to  reduce  DNS  lookups  
–  Use  Keep-­‐Alive  (persistent)  connec=ons,  to  allow  the  same  HTTP  
connec=on  to  be  reused  for  requests  going  to  the  same  host  
–  Use  fewer  domains.  Can  be  in  conflict  with  
•  3rd  party  content  integra=on    
•  Domain  sharding  for  improved  concurrent  download  (See  Other  Rules  B)  
 Rule  10:  Minify  JavaScript  
•  Removes  unnecessary  white  space,  comments  etc  from  JS  
•  Reduces  size,  and  makes  it  faster  to  download  
•  Harder  to  read  &  debug,  so  make  it  op=onal  (during  dev)  
and  have  un-­‐minified  versions  
•  Not  as  important  as  GZIP  Compression  (see  Rule  4),  but  s=ll  
worth  it  
•  Can  o8en  be  applied  as  you’re  combining  files  to  reduce  
HTTP  requests  (see  Rule  1)  
•  Same  idea  can  be  used  for  CSS,  but  gains  are  typically  not  
as  big  
–  Usually  beQer  to  op=mize  CSS    
•  Get  rid  of  duplicate  or  unused  rules  
•  Par=cularly  ones  for  browsers  you  don’t  support  anymore  –  IE6  &  7!!  
 Rule  11:  Avoid  Redirects  
•  3xx  HTTP  Status  codes  
–  Mostly  301  &  302  
•  Add  expires  headers  to  cache  redirects  
•  Worst  form  of  blocking  
–  On  main  HTML  page  or  CSS  files  browser  can’t  start  rendering  at  all  
•  Some=mes  redirects  can  be  avoided  using  rewrites  at  the  server  
(e.g.  mod_rewrite)  
•  Redirects  are  some=mes  used  to  make  sure  that  all  requests  that  
show  the  same  data  are  associated  with  the  same  URL  
–  Improved  SEO  by  preven=ng  duplicate  content  issues  
–  Consider  specifying  a  canonical  URL  instead.  It  tells  search  engines  
(like  google)  to  give  all  the  SEO  rank  to  the  canonical  URL  rather  than  
the  actual  page  URL  
–  <link  rel="canonical"  href=”…”/>  
 Rule  12:  Remove  Duplicate  Scripts  
•  Different  components  on  a  page  require  the  same  JS  
file,  and  somehow  the  script  link  gets  added  in  HTML  
more  than  once  
–  More  likely  when  you’re  page  is  composed  of  
“components”  each  of  which  needs  a  certain  set  of  
resources,  and  there  are  dependencies  between  resources  
•  Modern  browsers  won’t  download  it  mul=ple  =mes  
(even  if  it’s  not  cached)  but  they  will  RUN  it  mul=ple  
=mes.    
•  Look  for  automated  solu=ons  to  this  
–  JAWR  (Java)  
–  Require.js  (JavaScript)  
 Rule  13:  Configure  ETags  
•  unique  iden=fier  returned  in  repsonse  
–  ETag:  "c8897e-­‐aee-­‐4165acf0"  
–  Last-­‐Modified:  Thu,  07  Jul  2013,  20:54:08  GMT  
•  Used  in  condi=onal  GET  requests  
–  If-­‐None-­‐Match:  "c8897e-­‐aee-­‐4165acf0"  
–  If-­‐Modified-­‐Since:  Thu,  07  Jul  2013,  20:54:08  GMT  
•  If  ETag  
–  matches  -­‐  304  returned,  no  content,  typically  very  fast  
–  doesn't  match  -­‐  full  content  is  returned  
•  For  Etags  to  be  useful,  they  must  return  the  same  value  for  the  same  
resource  across  all  your  servers  
–  By  default  Apache  and  IIS  use  file  based  tags  (inode,  file  changenumber)  
–  Some=mes  beQer  to  turn  if  off  and  use  only  expires  header  
•  Esp  if  you’re  using  versioned  urls,  where  the  URL  will  change  if  the  content  does  
 Rule  14:  Make  Ajax  Cacheable  
•  XHR,  JSON,  Iframe  and  dynamic  scripts  can  
s=ll  be  cached,  minified  and  gzipped  
•  A  personalized  response  should  s=ll  be  
cacheable  by  that  person  
•  BEWARE:  Jquery.getScript()  adds  a  cache-­‐
buster  string  to  the  URL  by  default  
–  ../script2.js?_=1373564323619  
–  Can  be  turned  of  globally,  but  if  you  want  request  by  request  control  then  
you’ll  need  to  just  use  the  underlying  normal  $.ajax  call.  
•  See  hQp://api.jquery.com/jQuery.getScript/  
 Other  Rules  A:  Op=mize  Images  
•  Images  make  up  a  large  amount  of  all  bandwidth  used  for  web  pages  
–  Much  is  o8en  wasted  
•  Lossless  
–  No  needed  data  is  lost.  E.g.  image  quality  is  maintained  
•  Works  by  stripping  comments,  padding,  using  beQer  compression  
•  E.g.  hQp://imageop=m.com/  for  mac  
–  Some=mes  changing  the  image  format  (PNG,  GIF,  JPG)  may  give  smaller  file  
size  
•  Can’t  always  do  this  if  you  need  transparency  
•  Lossy  
–  Image  quality  is  reduced  (e.g.  using  less  colors,  lines  are  not  as  smooth  etc).  
For  large  images  this  is  o8en  not  no=ceable.  
•  Don’t  rely  on  browser  to  resize  images  
–  Wasted  bandwidth  if  you  download  a  large  image  then  scale  it  
–  Get  the  server  to  do  this  and  cache  it  e.g.  
•  Apache  HTTP:  Apache::Imager:Resize  
•  NGINX:  HQpImageFilterModule  
 Other  Rules  B:  Domain  Sharding  
•  Modern  browsers  allow  6  concurrent  downloads  for  each  domain  
•  If  you  have  one  or  more  “dominant  domains”  you  may  consider  using  
“domain  sharding”  to  allow  more  assets  to  be  download  concurrently  
–  images.mysite.com  -­‐>  i1.mysite.com,  i2.mysite.com  
•  Beware!  
–  There  is  a  point  of  diminishing  return  where  performance  will  get  worse  as  
you  add  more  domains.  Typically  it’s  4  shards.  Why?  
•  More  DNS  lookups  to  be  done  (See  Rule  9)  
•  More  Connec=ons  to  be  established  (takes  =me)  
•  Thread  swapping/conten=on  in  browser  (less  of  an  issue  with  today’s  mul=-­‐core  
processors)  
•  S+ll  have  the  same  bandwidth  internet  connec+on  that  now  has  many  more  
downloads  running  over  it  
–  Assets  may  take  longer  to  download,  and  this  can  impact  consumer  experience  (real  or  
perceived)  
–  E.g.  If  CSS  downloads  are  slowed  by  sharing  bandwidth  with  images  further  down  the  page  
then  the  page  rendering  will  be  impacted  
•  Measure,  Measure,  Measure!  
 

hQp://www.stevesouders.com/blog/2009/05/12/sharding-­‐dominant-­‐domains/  
 Other  Rules  C:  Beware  3rd  Party  Content  

•  Ads,  Chat  popups,  toolbars  etc  

•  Ideally  defer  these  if  possible  
•  Some  s=ll  use  document.write  
–  Try  and  IFrame  if  width  and  height  are  known  
•  If  they’re  downloading  inline,  you  put  the  
performance  of  YOUR  site  in  THEIR  hands  
–  BEWARE!!!  
–  E.g.  Major  news  events  can  cause  a  huge  increase  in  
traffic  for  some  news  sites.  These  may  use  the  same  
3rd  party  sites  as  your  site  does.  
•  Net  Effect:  Your  site  gets  hosed  L  
 Other  Rules  D:  Know  your  IFrames  

•  Iframes  are  a  useful  tool,  and  not  just  to  “import”  content  from  
other  sites  (in  a  sandbox)  
–  Read  “http://www.stevesouders.com/blog/2009/06/03/using-iframes-
sparingly/”  
•  Content  downloads  in  parallel  to  the  main  page  
–  Main  page  load  is  blocked  un=l  the  Iframe  page  complete!  
–  Shares  the  main  page  connec=on  pool  
–  Consider  using  Async  Iframe  technique  to  prevent  this  blocking  (if  it’s  
impac‚ul  to  your  site)  
•  Can  be  used  for  other  things  also  
–  Non-­‐blocking  image  loading  (get  image  into  cache)  
•  4  Great  techniques  outlined  here:  
–  http://www.aaronpeters.nl/blog/iframe-loading-techniques-
performance?%3E!
 The  BaQle:  Features  vs  Performance  
•  All  of  you  that  pursue  a  future  in  so8ware  development  will  face  a  
baQle  with  the  product/business/design  groups  
•  “Must  have”  feature  X  will  impact  the  performance  of  your  
website,  perhaps  significantly  
–  O8en  the  performance  issue  is  not  known  about  un=l  late  on  in  the  
feature  development/tes=ng  
–  Some=mes  there  is  no  easy/prac=cal/cheap  solu=on  
•  What  can  you?  
–  O8en  all  you  can  do  is  quan=fy  and  raise  awareness  of  the  risks  and  
impact  of  doing  X,  and  let  others  make  a  decision  
–  What  happens  depends  on  how  seriously  performance  is  taken  in  your  
organiza=on  
–  If  it  goes  ahead  anyway,  measure  
•  Performance  impact  
•  Actual  revenue  impact  (up  or  down)