Lots of ways to speed up your site
ā¢
766 likesā¢143,138 views
The document discusses various techniques for improving website speed, organized into three main categories: transmission, rendering, and serving. Transmission-focused techniques include image compression, minification, HTTP compression, and expires headers. Rendering optimizations involve load order, lazy loading, and parallel downloads. Serving improvements involve using a CDN, disk caching, keep-alive headers, and pre-rendering. The document emphasizes testing techniques like Google PageSpeed Insights and HAR files to diagnose bottlenecks and measure the impact of changes.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Lots of ways to speed up your site
Similar to Lots of ways to speed up your site (20)
More from Ian Lurie
More from Ian Lurie (20)
Recently uploaded
Recently uploaded (20)
Lots of ways to speed up your site
- 1. @portentint WAYS TO MAKE YOUR SITE FASTER THE SITE SPEED DOWNLOAD
- 3. @portentint SITE SPEED IS A LITTLE SCARY WHAT THE HELL IS TTFB?!!!
- 5. @portentint Iāll explain relative diļ¬culā«,ļ¬ā¬ impact & when to use each technique
- 7. @portentint These are just the techniques Iāve found to be the biggest wins
- 9. @portentint HEREāS THE THING FASTER IS BETTER
- 15. @portentint WHY? $- $10.00 $20.00 $30.00 1 2 3 4 5 6 7 8 9 Load time (seconds) Page Value vs. Load Time
- 16. @portentint WHY? $- $10.00 $20.00 $30.00 1 2 3 4 5 6 7 8 9 Load time (seconds) Page Value vs. Load Time WHY NOT?!!!!
- 22. @portentint GOOGLE PAGE SPEED INSIGHTS BASIC ANALYSIS
- 25. @portentint YSLOW READ YOUR WEB SITEāS MIND
- 30. @portentint Captures many important stats Hard-to-read HAR
- 31. @portentint WHY YOU CANāT TRUST TOOLS
- 32. @portentint Webpagetest.org: > 8 seconds
- 35. @portentint USE HAR SITE SPEED SUPERPOWERS
- 36. @portentint HAR: A direct, step-by-step view of site load & rendering
- 37. @portentint
- 38. @portentint
- 39. @portentint
- 40. @portentint
- 41. @portentint DIAGNOSING BOTTLENECKS & SPEEDING UP YOUR SITE
- 43. @portentint WHY START WITH TRANSMISSION? ITāS GOT THE EASIEST WINS
- 44. @portentint Blue = Download time Itās about bandwidth
- 47. @portentint HAR
- 48. @portentint JPG format, 100% qualiā«,ļ¬ā¬ 800 x 540: 400kb
- 49. @portentint JPG format, 90% qualiā«,ļ¬ā¬ 800 x 540: 217kb
- 50. @portentint JPG format, 80% qualiā«,ļ¬ā¬ 800 x 540: 100kb
- 51. @portentint JPG format, 60% qualiā«,ļ¬ā¬ 800 x 540: 67kb
- 53. @portentint ā¦But it only does png
- 54. @portentint Compression tools Imageoptim (Mac) Caesium (PC) Fireworks/Photoshop
- 55. @portentint Start at 60% JPG and work your way up/down
- 56. @portentint Start at 128 color PNG
- 57. @portentint USE WHEN WHY THE HELL NOT?!
- 58. @portentint Use the right image format diļ¬culā«:ļ¬ā¬ impact:
- 59. @portentint PNG format, 800 x 540: 1,000kb
- 60. @portentint JPG format, 100% qualiā«:ļ¬ā¬ 60kb
- 61. @portentint PNG format, 32m color: 13kb
- 62. @portentint PNG format, 256k color: 8kb
- 63. @portentint USE WHEN WHY THE HELL NOT?!
- 68. @portentint Use .MIN.JS version of javascript libraries
- 74. @portentint Lossless compression of HTML, javascript, css, other ļ¬les
- 75. @portentint Hey, thanks! Iāll extract it here. Iām going to compress these files for you so they arrive more quickly.
- 81. @portentint Not always possible with 3rd-parā«ļ¬ā¬ scripts
- 82. @portentint NOT OVER SSLunless you really know what youāre doing
- 85. @portentint this file doesnāt change that often. ok, iāll save it to my hard drive.
- 87. @portentint Not possible w/ 3rd-parā«ļ¬ā¬ scripts
- 91. @portentint USE WHEN Site uses many static ļ¬les
- 94. @portentint Itās about browser performance How quickly can a browser ādrawā this page?
- 96. @portentint This line HAR view This number
- 97. @portentint APPARENT RENDER TIME MEASURED RENDER TIME
- 99. @portentint CSS ļ¬rst. Javascript last.
- 100. @portentint <script src=āscript.jsā defer> Load in parallel, donāt block
- 101. @portentint <script src=āscript.jsā async> Load in parallel, execute as soon as possible
- 104. @portentint HAR
- 105. @portentint May break 3rd-parā«ļ¬ā¬ javascript
- 110. @portentint USE WHEN You can use multiple subdomains You use a CDN
- 112. @portentint 35,000 lines of code Render time: 1.5s html: 900kb
- 113. @portentint why?
- 114. @portentint Put in .css instead
- 118. @portentint At least get rid of the white space
- 121. @portentint Image loads when I scroll to here
- 123. @portentint USE WHEN You have below-the-fold images You have a gallery
- 125. @portentint HAR
- 126. @portentint <link rel="dns-prefetch" href="//domainname.com" />āØ <link rel=ādns-prefetchā href=āhttps://api.twitter.comā />
- 128. @portentint You go to this page a lot. Iām going to get it ready ahead of time.
- 130. @portentint
- 131. @portentint <link rel="prerender" href=āimages/kittens.jpg"> Load ļ¬le in advance
- 132. @portentint <link rel=āprefetch" href="http://my-site.com/bar.html"> Load & render page in advance
- 133. @portentint USE WHEN You know certain pages dominate
- 135. @portentint SERVING
- 137. @portentint TTFB: Time To First Byte
- 139. @portentint HAR
- 140. @portentint Time to First Byte (TTFB) should not > 500ms
- 141. @portentint But <250ms is beā«ļ¬ā¬er
- 144. @portentint CDN
- 145. @portentint A lot of work, but also helps with hā«ļ¬ā¬p compression, parallel loading, cookieless delivery, expires headers
- 147. @portentint disk & query caching diļ¬culā«:ļ¬ā¬ impact:
- 149. @portentint Thatās a long time. Are you using disk caching?
- 150. @portentint Stalled may indicate a page generation boā«ļ¬ā¬leneck. Use disk/query caching
- 153. @portentint No keep-alive Sure! may i have index.html?
- 154. @portentint No keep-alive Sure! may i have index.html? ok! can I have styles.css? uh, ok
- 155. @portentint No keep-alive Sure! may i have index.html? ok! can I have styles.css? uh, okthanks! can i have jquery.js?
- 156. @portentint No keep-alive Sure! may i have index.html? ok! can I have styles.css? uh, okthanks! can i have jquery.js? can i have image.gif?
- 157. @portentint Maintains connection, so fewer āhandshakesā Keep-alive
- 158. @portentint Keep-alive Sure! can i have index.html, image.gif, jquery.js and styles.css please?
- 164. @portentint Request page Store rendered page Deliver page Generate page Web/application server Phantomjs Cache server
- 167. @portentint GOOGLE AMP? FACEBOOK INSTANT PAGES?
- 168. @portentint First, do it right
- 170. @portentint Sprites/Reduce HTTP calls Responsive image scaling CSS optimization Javascript optimization Cookieless delivery
- 172. @portentint SERVING
Editor's Notes
- Thank you so so much
- Here are the links
- Here are the links
- This is going to be a super rapid-fire walk through site speed issues and how to deal with them.. Itāll be a bit terrifying if youāre not a serious nerd.
- The main goal here is to walk through it all
- and get you an idea of relative impact/difficulty for each technique. With that, you can decide what to do next and research if necessary.
- Everythingās rated by difficulty and impact.
- And, these arenāt every technique. Theyāre just the ones Iāve found to offer the most impact for the time and money spent.
- Well, of course, faster is better.
- You do need to test stuff. Iāll bring that up a few times.
- If you put in the effort to create great content, donāt kill it w/ a slow site.
- There is SOME correlation to organic search rankings. But itās weak. Google says itās a ātie breaker.ā
- The correlation to lead generation and sales, on the other hand, is VERY strong.
- Getting under 2 seconds generates a very high return.
- So the real question is: Why on earth would you not do this? Before we go through the techniques and tricks, though, I need to talk about bottlenecks and measurement.
- There are three places that can slow sites down ā three bottlenecks or chokepoints.
- Serving the content ā the web server generating web pages and content ā is the first bottleneck. Itās hard to make a site faster if the serverās slow.
- The bottleneck most people focus on is transmission: Basically, how your site uses bandwidth.
- And the most-forgotten bottleneck is rendering. Your browser has to draw the page or content. If the page/content has problems, it can slow rendering, which creates a slower perceived load time.
- There are tools that let you measure and diagnose issues at all three chokepoints.
- If you want basic, easy-to-read site speed diagnosis, Google Page Speed Insights is great. If youāre just starting out with a site performance audit, start here.
- Google PageSpeed Insights mostly focuses on transmission ā on bandwidth.
- Donāt worry ā itās in the link
- Yslow has more oomph. If you want to really dig I, Yslow looks at more metrics.
- Yslow is very, very powerful.
- Itās less intuitive. But itās worth using if youāve exhausted Google PageSpeed Insights
- WebPageTest.org ā Iād love to love it. Itās just got some issues.
- It captures such a nice set of metrics. But the diagnostics and the HTTP Archive are harder to get at.
- When youāre ready to really nerd out ā learn to read and use an HTTP Archive, or HAR.
- You can generate it in Chrome w/ a few clicks.
- Just open the console, refresh the page, and youāre good to go.
- Now we get to the heavy stuff: How to actually diagnose and fix/optimize
- Starting w/ Transmission
- In this HAR diagram, the blue line is download time. Itās an indicator of bandwidth used.
- This is the single easiest win in all of site speed.
- Google PageSpeed will provide the analysis
- And, of course, the HAR will do it.
- A few quick examples. This image totally uncompressed was 4 megabytes. Doing even a tiny bit of compression reduced it to 400kb.
- Look at what happens ā can you see a difference? No? But itās half the size.
- Even smaller
- And yes, even smaller
- PageSpeed isnāt bad, either, butā¦
- It only uses lossless ā PNG - compression.
- You can use Photoshop, of course, but here are two other tools. Be very careful about using web-based compression tools, Make sure theyāre reputable.
- Always always always do this.
- Using the right image format is another one
- JPG is for photos, PNG is really for line art. So convert my friend to PNG and it balloons back to 1 megabyte.
- Put our logo in JPG and itās 60k
- In PNG, itās 13kb. And this isnāt even the vector version
- Take out some colors and itās down to 8kb.
- Always always always do this.
- This is an unminified file.
- This is the same file, minified. The difference? Tabs, blank lines are all removed. Invisible characters are still characters!!! Removing them from a large file makes a huge difference. Obviously, keep an editable version of the files. How can you do this?
- In Google PageSpeed, you can download the minified files with a click.
- But many libraries already come w/ minified versions ā Jquery, for example.
- Again, thereās no reason not to.
- Seriously. Doesnāt get much easier.
- Iāve never seen this break anything. Iāve heard rumors it can cause issues, which is why I advocate testing. But in 20 years Iāve never seen an issue.
- Set expires headers for static files
- When you set far-future expires headers, the server tells visiting browsers that a particular file isnāt going to change any time soon.
- Google PageSpeed will show you issues. So will Yslow, etc., but PageSpeed is easy.
- But you canāt usually do this w/ third-party scripts.
- Really, itās any site. But expires headers work well for āstaticā files that donāt change that often. So thatās when/where to use it.
- Test all of these things. Again ā I havenāt seen them break anything, butā¦
- Some resources can block page load.
- At itās most basic: Load CSS first. Defer javascript as long as possible. That means all CSS includes should come before any javascript includes. But itās more subtle than that.
- You can load javascript in parallel.
- Google will show render-blocking javascript. Thatās the stuff thatās in the wrong load order ā the page is stuck.
- Use HAR to really drill down and get a look at what loads when.
- Do the same for javascript. This ensures visiting browsers only load the javascript/css once per session. They they cache it locally.
- Yslow is my favorite tool here.
- I donāt know why youād write crappy code. Itās actually more work.
- When you set far-future expires headers, the server tells visiting browsers that a particular file isnāt going to change any time soon.
- This not only means faster load time because server is closer ā it also means the main server doesnāt have to retrieve and deliver the files.
- Retrieving from a database is slower than retrieving from disk (you can also cache in memory ā thatās a separate topic, really)
- I wonāt go into a lot of detail here ā code acceleration usually caches executed code so that the server doesnāt have to re-run the code.