1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
|
[[!meta title="Chasing Performance"]]
[[!meta date="2017-11-20"]]
## Update
This post is no longer relevant since this blog has been redesigned since. I'm keeping this article up as a point of reference.
- - -
So I decided to participate in Smashing Mag's <a href="https://www.smashingmagazine.com/2017/10/front-end-performance-challenge/">Front End Performance Challenge</a>, not only for the potential of winning the prize but to further experiment with optimizing my site. (Web performance is a passion of mine)
Below I will breakdown the before & after statistics of my personal site and what changes I made in great detail.
I will be using both my homepage and the image-heavy article I recently wrote, <a href="/blog/the-death-of-personality/">The Death of Personality</a>, as the basis for my tests.
### Lighthouse Score - Homepage
<a href="/public/images/lighthouse-homepage-original.webp">Full source original stats</a> // <a href="/public/images/lighthouse-homepage-updated.webp">Full source updated stats</a>
<table>
<thead>
<tr>
<th>Stats</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>Performance</td>
<td>82</td>
<td>98</td>
</tr>
<tr>
<td>Accessibility</td>
<td>100</td>
<td>100</td>
</tr>
<tr>
<td>Best Practices</td>
<td>75</td>
<td>94</td>
</tr>
</tbody>
</table>
### Lighthouse Score - Article Page
<a href="public/images/lighthouse-article-original.webp">Full source original stats</a> // <a href="public/images/lighthouse-article-updated.webp">Full source updated stats</a>
<table>
<thead>
<tr>
<th>Stats</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>Performance</td>
<td>39</td>
<td>96</td>
</tr>
<tr>
<td>Accessibility</td>
<td>97</td>
<td>100</td>
</tr>
<tr>
<td>Best Practices</td>
<td>69</td>
<td>94</td>
</tr>
</tbody>
</table>
### Web Page Test - Homepage
<a href="/public/images/webpagetest-homepage-original.webp">Full source original stats</a> // <a href="/public/images/webpagetest-homepage-updated.webp">Full source updated stats</a>
<table>
<thead>
<tr>
<th>Stats</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>Initial Load Time</td>
<td>0.91s</td>
<td class="after bar">0.41s</td>
</tr>
<tr>
<td>Visually Complete</td>
<td>0.9s</td>
<td>0.7s</td>
</tr>
<tr>
<td>Fully Loaded</td>
<td>0.94s</td>
<td>0.65s</td>
</tr>
</tbody>
</table>
### Web Page Test - Article Page
<a href="/public/images/webpagetest-article-original.webp">Full source original stats</a> // <a href="/public/images/webpagetest-article-updated.webp">Full source updated stats</a>
<table>
<thead>
<tr>
<th>Stats</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>Initial Load Time</td>
<td>4.7s</td>
<td>0.5s</td>
</tr>
<tr>
<td>Visually Complete</td>
<td>3.1s</td>
<td>0.8s</td>
</tr>
<tr>
<td>Fully Loaded</td>
<td>4.8s</td>
<td>0.67s</td>
</tr>
</tbody>
</table>
### Quick Look
Though my homepage only made some minor speed performance enhancements, my article post's initial load time was slimmed down by a **whopping 4.2 seconds!** That's pretty incredible and very noticeable from an end-user's perspective.
### So - What Changed?
Webfonts
I'm not using any webfonts but instead defaulting to the user's OS System Fonts. I love custom typefaces but performance takes just too much of a hit on my personal site to bother with them.
body {
font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen,Ubuntu,Cantarell,"Open Sans","Helvetica Neue",sans-serif,"Sans Serif",Icons;
}
For reference, there are some things you should to look out for when using custom typefaces:
- Readability and accessibility
- Possible extra overhead loading in a custom @font-face
- Try to avoid any <a href="https://css-tricks.com/fout-foit-foft/">FOUT, FOIT, FOFT</a>
- Don't go down the rabbit hole of using 3rd party plugins to optimize something as basic as a typeface
### Critical CSS
This part was easy. In order to avoid the weird styling 'pops' present on some websites when initially loading with slow connections, it's best to place all your most critical styling inline and then load your external CSS once everything else has loaded.
On top of that, I decided to also implement Filament Group's <a href="https://github.com/filamentgroup/loadCSS">loadCSS</a> function to load my CSS asynchronously. If you are not currently using this in any of your projects; stop reading this and go do it! It's a game changer.
### Critical JavaScript
My personal site only uses a small amount of JavaScript on the article post Jekyll template pages. By using the <code>defer</code> property I can be sure to load the <code>IntersectionObserver</code> API polyfill after the rest of the DOM as finished loading.
<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=IntersectionObserver" defer>
I could probably optimize this further by only calling these scripts if an image is actually present in the article post, but this fits my needs nicely as is.
### Responsive Images
The only images I use are those included in supported blog posts, so the first step was making sure to only call <code>iolazy.min.js</code> on those specific template pages. The next step was defaulting to <code>webp</code> image formats with a lossless <code>jpg</code> fall-back with the help of the <code>picture</code> element:
<span class="sidenote">I've also included responsive image sizes for further optimization based on screen size and loading speeds.</span>
<figure>
<picture
<source type="image/webp"
data-srcset="
/images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_200.webp 200w,
/images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_1400.webp 1400w"
class="lazyload"/>
<img
sizes="(max-width: 1400px) 100vw, 1400px"
data-srcset="
/images/articles/flat-design-toggles_qfre51_c_scale,w_200.webp 200w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_727.webp 727w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_1065.webp 1065w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp 1400w"
src="/images/placeholder.webp"
alt="Toggles Comparison"
class="lazyload"/>
</picture>
</figure>
What about users with JavaScript disabled I hear you ask? It's time for <code>noscript</code> to save the day:
<noscript>
<picture>
<source type="image/webp"
srcset="
/images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_200.webp 200w,
/images/articles/webp/flat-design-toggles_p0v2hv_c_scale,w_1400.webp 1400w">
<img
sizes="(max-width: 1400px) 100vw, 1400px"
srcset="
/images/articles/flat-design-toggles_qfre51_c_scale,w_200.webp 200w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_727.webp 727w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_1065.webp 1065w,
/images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp 1400w"
src="/images/articles/flat-design-toggles_qfre51_c_scale,w_1400.webp"
alt="Toggles Comparison"/>
</picture>
</noscript>
### HTTPS & Caching
The Lighthouse audit also suggested implementing an SSL certificate (something I've been meaning to do for a while anyway) and also utilize CDN caching. So it was Cloudflare to the rescue!
Since my website is hosted through Github, setting up a *free* SSL certificate and enabling site-wide caching was a breeze. If you're interested in setting this up yourself, step-by-step instructions can be found <a href="https://gist.github.com/cvan/8630f847f579f90e0c014dc5199c337b">here</a>.
This simple update helped boost my best practices score from a 69 to a 94. Yet another performance enhancement you should be enabling for all your current and future projects!
## Performance Happiness
Overall I'm pretty content with the **major** performance boost my site has received from these fairly *minor* updates and I hope this article inspires other designers and developers to jump into updating their own site/app performance speeds. The pay-off is truly worth it!
### Some Extra Reading Material
- <a href="https://www.amazon.ca/Web-Performance-Action-Building-Faster/dp/1617293776/ref=sr_1_1?ie=UTF8&qid=1510585897&sr=8-1&keywords=web+performance+in+action">Web Performance in Action</a> by <i>Jeremy Wagner</i>
- <a href="https://www.amazon.ca/Responsible-Responsive-Design-Scott-Jehl/dp/1937557162/ref=sr_1_1?s=books&ie=UTF8&qid=1510585972&sr=1-1&keywords=responsible+responsive+design">Responsible Responsive Design</a> by <i>Scott Jehl</i>
- <a href="https://www.amazon.ca/Designing-Progressive-Enhancement-Building-Everyone/dp/0321658884/ref=sr_1_1?s=books&ie=UTF8&qid=1510586005&sr=1-1">Designing with Progressive Enhancement: Building the Web that Works for Everyone</a> by <i>Todd Parker, Scott Jehl, Maggie Costello Wachs, Patty Toland</i>
|