Lots of ways to speed up your site

Editor's Notes

1. Thank you so so much
2. Here are the links
3. Here are the links
4. 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.
5. The main goal here is to walk through it all
6. 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.
7. Everything’s rated by difficulty and impact.
8. 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.
9. Well, of course, faster is better.
10. You do need to test stuff. I’ll bring that up a few times.
11. If you put in the effort to create great content, don’t kill it w/ a slow site.
12. There is SOME correlation to organic search rankings. But it’s weak. Google says it’s a ‘tie breaker.’
13. The correlation to lead generation and sales, on the other hand, is VERY strong.
14. Getting under 2 seconds generates a very high return.
15. 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.
16. There are three places that can slow sites down – three bottlenecks or chokepoints.
17. 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.
18. The bottleneck most people focus on is transmission: Basically, how your site uses bandwidth.
19. 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.
20. There are tools that let you measure and diagnose issues at all three chokepoints.
21. 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.
22. Google PageSpeed Insights mostly focuses on transmission – on bandwidth.
23. Don’t worry – it’s in the link
24. Yslow has more oomph. If you want to really dig I, Yslow looks at more metrics.
25. Yslow is very, very powerful.
26. It’s less intuitive. But it’s worth using if you’ve exhausted Google PageSpeed Insights
27. WebPageTest.org – I’d love to love it. It’s just got some issues.
28. It captures such a nice set of metrics. But the diagnostics and the HTTP Archive are harder to get at.
29. When you’re ready to really nerd out – learn to read and use an HTTP Archive, or HAR.
30. You can generate it in Chrome w/ a few clicks.
31. Just open the console, refresh the page, and you’re good to go.
32. Now we get to the heavy stuff: How to actually diagnose and fix/optimize
33. Starting w/ Transmission
34. In this HAR diagram, the blue line is download time. It’s an indicator of bandwidth used.
35. This is the single easiest win in all of site speed.
36. Google PageSpeed will provide the analysis
37. And, of course, the HAR will do it.
38. A few quick examples. This image totally uncompressed was 4 megabytes. Doing even a tiny bit of compression reduced it to 400kb.
39. Look at what happens – can you see a difference? No? But it’s half the size.
40. Even smaller
41. And yes, even smaller
42. PageSpeed isn’t bad, either, but…
43. It only uses lossless – PNG - compression.
44. 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.
45. Always always always do this.
46. Using the right image format is another one
47. JPG is for photos, PNG is really for line art. So convert my friend to PNG and it balloons back to 1 megabyte.
48. Put our logo in JPG and it’s 60k
49. In PNG, it’s 13kb. And this isn’t even the vector version
50. Take out some colors and it’s down to 8kb.
51. Always always always do this.
52. This is an unminified file.
53. 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?
54. In Google PageSpeed, you can download the minified files with a click.
55. But many libraries already come w/ minified versions – Jquery, for example.
56. Again, there’s no reason not to.
57. Seriously. Doesn’t get much easier.
58. 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.
59. Set expires headers for static files
60. When you set far-future expires headers, the server tells visiting browsers that a particular file isn’t going to change any time soon.
61. Google PageSpeed will show you issues. So will Yslow, etc., but PageSpeed is easy.
62. But you can’t usually do this w/ third-party scripts.
63. 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.
64. Test all of these things. Again – I haven’t seen them break anything, but…
65. Some resources can block page load.
66. 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.
67. You can load javascript in parallel.
68. Google will show render-blocking javascript. That’s the stuff that’s in the wrong load order – the page is stuck.
69. Use HAR to really drill down and get a look at what loads when.
70. Do the same for javascript. This ensures visiting browsers only load the javascript/css once per session. They they cache it locally.
71. Yslow is my favorite tool here.
72. I don’t know why you’d write crappy code. It’s actually more work.
73. When you set far-future expires headers, the server tells visiting browsers that a particular file isn’t going to change any time soon.
74. 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.
75. Retrieving from a database is slower than retrieving from disk (you can also cache in memory – that’s a separate topic, really)
76. 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.