Shifting your site into
    the next gear




                                                                            ...
Hello there...
I’m Chris.
It is great to be in Sweden...
...especially when you live in
          England...
Ok, I originally meant not to
 make any naughty jokes.
But then I saw the Adwords
Robert seems to have bought
        for GeekMeet.
... enough of this, let’s get
         serious ...
The performance of your web
product is immensely important
And there are several small
  tricks and ideas that can
 increase the performance
        significantly.
There is a lot of research
being done on the subject in
    a lot of companies...
...and this information is
available for free for you.
I’ll provide the links and
       names later...
...but for now let’s see what is
    slowing our sites down.
http://www.flickr.com/photos/pikerslanefarm/2428232674/




Things that slow you down
<script>
JavaScript is awesome.
Browsers think so, too.
Which means that every time
they encounter a script node
     they take a break.

 <script>         </script>
Rendering stops and the
JavaScript parser takes over.
If there is code inside the tag,
   this code is analyzed and
executed before the browser
    goes back to rendering.
If there is a src attribute, the
 file it points to gets loaded,
     parsed and executed.
This can take time as the
  browser (with third party
 files) needs to get the right
domain information, contact
the other...
This gets worse the more
  script nodes you use.
The first question is then
  where to put scripts?
The gospel according to
    Heilmann, 2006:
<!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot;
 quot;http://www.w3.org/TR/html4/strict.dtdquot;>
<html lang=quo...
This has some benefits:
You can be sure your
JavaScript is loaded before
the document is displayed.
You make it easier for other
developers to debug – they
know where the scripts are.
On the other hand...
You delay the display of the
page until all the scripts are
  loaded and executed.
You need to delay the access
  to any HTML to change or
enhance until it is available –
    onload, onavailable,
      onc...
This is hacky!
The gospel according to
performance specialists
      2007/2008:
<!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot;
 quot;http://www.w3.org/TR/html4/strict.dtdquot;>
<html lang=quo...
The benefits are:
Your scripts don’t delay the
  rendering of the HTML.
HTML is available for
   enhancing.
The problems:
You don’t put scripts where
 people normally expect
          them.
The HTML is already available
 for people to interact with
 before you can apply your
   enhancement voodoo.
The recipe for performance and
       usability success?
Of course you need testing on
 your apps and sites to find
    your perfect solution...
But here are some ideas:
How about a mix of both?
<!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot;
 quot;http://www.w3.org/TR/html4/strict.dtdquot;>
<html lang=quo...
You can even execute
delayed without hacks.
<!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot;
 quot;http://www.w3.org/TR/html4/strict.dtdquot;>
<html lang=quo...
The first script can set a class
called js on the body of the
          document.
Which allows you to define
 two styles, one for the non-
scripting version and one for
      the dynamic one.
In the dynamic one you hide
 the problematic elements
   that could be activated
        prematurely.
Once the functionality has
been added, add another
  class that undoes this.
.js #buttons{
  position:absolute;
  top:0;
  left:-6000px;
}
.jsloaded #buttons{
  position:relative;
  top:0;
  left:0;
}
CSS parsers are very fast!
What about the multiple
     scripts issue?
Chunking your JavaScript into
several includes all doing one
job at a time is a great idea to
     keep your solutions
   ...
<script type=quot;text/javascriptquot;   src=quot;config.jsquot;>
</script>
<script type=quot;text/javascriptquot;   src=q...
This does not mean though
that you need to add all of
 them as single includes.
You can easily write a
backend script that does that
          for you:
<script type=quot;text/javascriptquot; src=quot;/pack/config/base/
effects/validation/widgetsquot;>
</script>
Fun things to do in this script:
Run through JSLint.
Minify.
Replace all strings with an
array lookup to stop IE from
 creating a string object for
        each string.
Instead of doing this every
time the page is loaded, you
  can make it part of a build
          process.
And don’t forget to cache the
           result!
Get a script that does most of
      that from Ed Eliot:
  http://www.ejeliot.com/blog/73
The other option is to be lazy.
Lazy loading is a concept to
load dependencies only when
   and if they are needed.
Your base.js could test for
 all the things that should
           work...
...and if they do, create script
  nodes dynamically to load
   the other, chunkier parts.
This is a pretty nice idea as it
only loads things when they
         are needed...
...thus saving server traffic
and diminishing loading time.
However, there are problems.
Asynchronous loading means
  you never know in which
order the loaded components
     come back to you...
You can work around that by
   creating callbacks, as
 explained on 24ways last
           year:
http://24ways.org/2007/ke...
There are a lot more issues,
for example that you might
block document.write() of
 bad code ads in your page.
Steve Souders and Stoyan
  Stefanof have the whole
           scoop:
   http://stevesouders.com/tests/
    delayed-script-...
What other things slow you
         down?
<img>
Images are what made the
   web what it is now.
Sure, linking text was a
       revolution.
But being able to get images
 on demand and store them
was something that triggered
 the “collector” in everyone.
Yeah, Pr0n.
Anyways, too many images
   slow down your site
       immensely.
The reasons are the same
delays you experience with
     external scripts...
...except images don’t stop
       the rendering.
However only a few get
  loaded at a time...
...as the number of parallel
connections of browsers is
limited (with good reason)
Which means you should cut
 down on the amount of
        images.
The best trick there is to use
        CSS sprites.
And again, Ed Eliot and Stuart
 Colville come to the rescue!
     http://spritegen.website-
         performance.org/
You use Spritegen by
uploading a zip of images...
...and it generates the CSS
and the sprite image for you!
It is also open source in case
you want to host it yourself.
How good are you in
optimizing images?
Probably not as good as you
      think you are.
A lot of bytes can be
squeezed out of images...
...without changing their
     visual outcome.
Choosing the right format in
the right version can be quite
            a drag.
And it doesn’t help that tools
 put all kind of pointless data
into images (edited with xyz,
         version abc...).
The easy way out?
http://smushit.com
What else could be a
     problem?
How about the amount of
  images on the page?
You can work around loading
  all the images by – once
again – delaying the loading.
The easy way is to prepend
the images with a dummy
  and then replace this.
<img src=”dummy.gif#kitten.jpg” alt=”a nice kitten”>
<img src=”dummy.gif#puppy.jpg” alt=”a nice puppy”>



<script type=qu...
The more complex but
cleverer way is to wait until
    the images are in the
          viewport.
  http://developer.yahoo....
You can see this trick in
action at shine.yahoo.com
      and YouTube.
It’d be cool if browsers did
  that anyways – anyone
     remember lowsrc?
What else is slowing us down?
<object>, err <embed> err...
Flash and other plugins have
 the same issues as <script>
            has.
You interfere with the
browsers’ normal rendering
  and they wait until the
     confusion is over.
The other issue of course is
that making embedding work
    and validate is a pain.
The solution for this is
progressively enhancing
   Flash embedding.
http://swfobject.googlecode.com
As you embed with JavaScript
 you can test for the correct
        Flash support.
And you can delay the
embedding by for example
enhancing an image when
   the user clicks on it.
SUMMARY TIME!
In general there are two
      things to do:
Collate and Delay :)
The tips and tools:

★   http://developer.yahoo.com/performance/
★   http://www.stevesouders.com/
★   http://website-perfo...
THANSK!
    Svenska?




                 Christian Heilmann

 http://scriptingenabled.org | http://wait-till-i.com

     ...
Shifting Gears
Shifting Gears
Shifting Gears
Shifting Gears
Upcoming SlideShare
Loading in...5
×

Shifting Gears

9,738

Published on

My first talk at geekmeet Sweden, talking about basics of web site performance.

Published in: Technology
0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,738
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
66
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide

Shifting Gears

  1. 1. Shifting your site into the next gear http://www.flickr.com/photos/fabiovenni/91780334/ Christian Heilmann | http://wait-till-i.com | http://twitter.com/codepo8 GeekMeet, Stockholm, Sweden, December 2008
  2. 2. Hello there...
  3. 3. I’m Chris.
  4. 4. It is great to be in Sweden...
  5. 5. ...especially when you live in England...
  6. 6. Ok, I originally meant not to make any naughty jokes.
  7. 7. But then I saw the Adwords Robert seems to have bought for GeekMeet.
  8. 8. ... enough of this, let’s get serious ...
  9. 9. The performance of your web product is immensely important
  10. 10. And there are several small tricks and ideas that can increase the performance significantly.
  11. 11. There is a lot of research being done on the subject in a lot of companies...
  12. 12. ...and this information is available for free for you.
  13. 13. I’ll provide the links and names later...
  14. 14. ...but for now let’s see what is slowing our sites down.
  15. 15. http://www.flickr.com/photos/pikerslanefarm/2428232674/ Things that slow you down
  16. 16. <script>
  17. 17. JavaScript is awesome.
  18. 18. Browsers think so, too.
  19. 19. Which means that every time they encounter a script node they take a break. <script> </script>
  20. 20. Rendering stops and the JavaScript parser takes over.
  21. 21. If there is code inside the tag, this code is analyzed and executed before the browser goes back to rendering.
  22. 22. If there is a src attribute, the file it points to gets loaded, parsed and executed.
  23. 23. This can take time as the browser (with third party files) needs to get the right domain information, contact the other server, get the file and then move on.
  24. 24. This gets worse the more script nodes you use.
  25. 25. The first question is then where to put scripts?
  26. 26. The gospel according to Heilmann, 2006:
  27. 27. <!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot; quot;http://www.w3.org/TR/html4/strict.dtdquot;> <html lang=quot;se-se(bork bork)quot;> <head> <meta http-equiv=quot;Content-Typequot; content=quot;text/ html; charset=utf-8quot; /> <title></title> <script type=quot;text/javascriptquot; src=quot;myscripts.jsquot;></script> </head> <body> <!-- lots of HTML here --> </body> </html>
  28. 28. This has some benefits:
  29. 29. You can be sure your JavaScript is loaded before the document is displayed.
  30. 30. You make it easier for other developers to debug – they know where the scripts are.
  31. 31. On the other hand...
  32. 32. You delay the display of the page until all the scripts are loaded and executed.
  33. 33. You need to delay the access to any HTML to change or enhance until it is available – onload, onavailable, oncontentloaded.
  34. 34. This is hacky!
  35. 35. The gospel according to performance specialists 2007/2008:
  36. 36. <!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot; quot;http://www.w3.org/TR/html4/strict.dtdquot;> <html lang=quot;se-se(bork bork)quot;> <head> <meta http-equiv=quot;Content-Typequot; content=quot;text/ html; charset=utf-8quot; /> <title></title> </head> <body> <!-- lots of HTML here --> <script type=quot;text/javascriptquot; src=quot;myscripts.jsquot;></script> </body> </html>
  37. 37. The benefits are:
  38. 38. Your scripts don’t delay the rendering of the HTML.
  39. 39. HTML is available for enhancing.
  40. 40. The problems:
  41. 41. You don’t put scripts where people normally expect them.
  42. 42. The HTML is already available for people to interact with before you can apply your enhancement voodoo.
  43. 43. The recipe for performance and usability success?
  44. 44. Of course you need testing on your apps and sites to find your perfect solution...
  45. 45. But here are some ideas:
  46. 46. How about a mix of both?
  47. 47. <!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot; quot;http://www.w3.org/TR/html4/strict.dtdquot;> <html lang=quot;se-se(bork bork)quot;> <head> <meta http-equiv=quot;Content-Typequot; content=quot;text/html; charset=utf-8quot; /> <title></title> <script type=quot;text/javascriptquot; src=quot;main.jsquot;></ script> </head> <body> <!-- lots of HTML here --> <script type=quot;text/javascriptquot; src=quot;secondary.jsquot;></ script> </body> </html>
  48. 48. You can even execute delayed without hacks.
  49. 49. <!DOCTYPE HTML PUBLIC quot;-//W3C//DTD HTML 4.01//ENquot; quot;http://www.w3.org/TR/html4/strict.dtdquot;> <html lang=quot;se-se(bork bork)quot;> <head> <meta http-equiv=quot;Content-Typequot; content=quot;text/html; charset=utf-8quot; /> <title></title> <script type=quot;text/javascriptquot; src=quot;main.jsquot;></ script> </head> <body> <!-- lots of HTML here --> <script type=quot;text/javascriptquot;>doStuff()</script> <script type=quot;text/javascriptquot; src=quot;secondary.jsquot;></ script> </body> </html>
  50. 50. The first script can set a class called js on the body of the document.
  51. 51. Which allows you to define two styles, one for the non- scripting version and one for the dynamic one.
  52. 52. In the dynamic one you hide the problematic elements that could be activated prematurely.
  53. 53. Once the functionality has been added, add another class that undoes this.
  54. 54. .js #buttons{ position:absolute; top:0; left:-6000px; } .jsloaded #buttons{ position:relative; top:0; left:0; }
  55. 55. CSS parsers are very fast!
  56. 56. What about the multiple scripts issue?
  57. 57. Chunking your JavaScript into several includes all doing one job at a time is a great idea to keep your solutions maintainable.
  58. 58. <script type=quot;text/javascriptquot; src=quot;config.jsquot;> </script> <script type=quot;text/javascriptquot; src=quot;base.jsquot;> </script> <script type=quot;text/javascriptquot; src=quot;effects.jsquot;> </script> <script type=quot;text/javascriptquot; src=quot;validation.jsquot;> </script> <script type=quot;text/javascriptquot; src=quot;widgets.jsquot;> </script>
  59. 59. This does not mean though that you need to add all of them as single includes.
  60. 60. You can easily write a backend script that does that for you:
  61. 61. <script type=quot;text/javascriptquot; src=quot;/pack/config/base/ effects/validation/widgetsquot;> </script>
  62. 62. Fun things to do in this script:
  63. 63. Run through JSLint.
  64. 64. Minify.
  65. 65. Replace all strings with an array lookup to stop IE from creating a string object for each string.
  66. 66. Instead of doing this every time the page is loaded, you can make it part of a build process.
  67. 67. And don’t forget to cache the result!
  68. 68. Get a script that does most of that from Ed Eliot: http://www.ejeliot.com/blog/73
  69. 69. The other option is to be lazy.
  70. 70. Lazy loading is a concept to load dependencies only when and if they are needed.
  71. 71. Your base.js could test for all the things that should work...
  72. 72. ...and if they do, create script nodes dynamically to load the other, chunkier parts.
  73. 73. This is a pretty nice idea as it only loads things when they are needed...
  74. 74. ...thus saving server traffic and diminishing loading time.
  75. 75. However, there are problems.
  76. 76. Asynchronous loading means you never know in which order the loaded components come back to you...
  77. 77. You can work around that by creating callbacks, as explained on 24ways last year: http://24ways.org/2007/keeping-javascript- dependencies-at-bay
  78. 78. There are a lot more issues, for example that you might block document.write() of bad code ads in your page.
  79. 79. Steve Souders and Stoyan Stefanof have the whole scoop: http://stevesouders.com/tests/ delayed-script-execution.php http://yuiblog.com/blog/2008/07/22/ non-blocking-scripts/
  80. 80. What other things slow you down?
  81. 81. <img>
  82. 82. Images are what made the web what it is now.
  83. 83. Sure, linking text was a revolution.
  84. 84. But being able to get images on demand and store them was something that triggered the “collector” in everyone.
  85. 85. Yeah, Pr0n.
  86. 86. Anyways, too many images slow down your site immensely.
  87. 87. The reasons are the same delays you experience with external scripts...
  88. 88. ...except images don’t stop the rendering.
  89. 89. However only a few get loaded at a time...
  90. 90. ...as the number of parallel connections of browsers is limited (with good reason)
  91. 91. Which means you should cut down on the amount of images.
  92. 92. The best trick there is to use CSS sprites.
  93. 93. And again, Ed Eliot and Stuart Colville come to the rescue! http://spritegen.website- performance.org/
  94. 94. You use Spritegen by uploading a zip of images...
  95. 95. ...and it generates the CSS and the sprite image for you!
  96. 96. It is also open source in case you want to host it yourself.
  97. 97. How good are you in optimizing images?
  98. 98. Probably not as good as you think you are.
  99. 99. A lot of bytes can be squeezed out of images...
  100. 100. ...without changing their visual outcome.
  101. 101. Choosing the right format in the right version can be quite a drag.
  102. 102. And it doesn’t help that tools put all kind of pointless data into images (edited with xyz, version abc...).
  103. 103. The easy way out?
  104. 104. http://smushit.com
  105. 105. What else could be a problem?
  106. 106. How about the amount of images on the page?
  107. 107. You can work around loading all the images by – once again – delaying the loading.
  108. 108. The easy way is to prepend the images with a dummy and then replace this.
  109. 109. <img src=”dummy.gif#kitten.jpg” alt=”a nice kitten”> <img src=”dummy.gif#puppy.jpg” alt=”a nice puppy”> <script type=quot;text/javascriptquot;> window.onload = function(){ var imgs = document.getElementsByTagName(‘img’); for(var i=0;imgs[i];i++){ var src = imgs[i].src; imgs[i].src = src.replace(‘dummy.gif#’,’’); } } </script>
  110. 110. The more complex but cleverer way is to wait until the images are in the viewport. http://developer.yahoo.com/yui/imageloader/
  111. 111. You can see this trick in action at shine.yahoo.com and YouTube.
  112. 112. It’d be cool if browsers did that anyways – anyone remember lowsrc?
  113. 113. What else is slowing us down?
  114. 114. <object>, err <embed> err...
  115. 115. Flash and other plugins have the same issues as <script> has.
  116. 116. You interfere with the browsers’ normal rendering and they wait until the confusion is over.
  117. 117. The other issue of course is that making embedding work and validate is a pain.
  118. 118. The solution for this is progressively enhancing Flash embedding.
  119. 119. http://swfobject.googlecode.com
  120. 120. As you embed with JavaScript you can test for the correct Flash support.
  121. 121. And you can delay the embedding by for example enhancing an image when the user clicks on it.
  122. 122. SUMMARY TIME!
  123. 123. In general there are two things to do:
  124. 124. Collate and Delay :)
  125. 125. The tips and tools: ★ http://developer.yahoo.com/performance/ ★ http://www.stevesouders.com/ ★ http://website-performance.org/ ★ YSlow: http://developer.yahoo.com/yslow/ ★ Hammerhead: http://stevesouders.com/hammerhead/
  126. 126. THANSK! Svenska? Christian Heilmann http://scriptingenabled.org | http://wait-till-i.com twitter/flickr: codepo8
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×