Last year I decided to check out my own personal site in Google PageSpeed Insights. Even though it’s only a simple static flat-file site, Google didn’t give it a very good score. I decided to see if things could be improved. This presentation covers what I discovered, and what I was able to do about it.
6. Built using Jekyll, a static site generator
No PHP, no database, just HTML, CSS and a tiny
bit of JavaScript
7. First of all, why bother when the site already
seemed pretty quick?
8. • It was a learning exercise for me
• I wanted to see how good a score I could get
• Plus, a certain amount of professional pride
was at stake
9. • Even if your site feels fast, it’s important to
resolve any underlying issues
• They are likely to become more and more
pronounced as a project scales up
• Google PageSpeed Insights highlighted a
number of problems
• And scored the site 68/100 for mobile, and
75/100 for desktop
14. CSS is a render-blocking resource
Inline critical CSS in the <head> to reduce
network request latency
The fewer HTTP requests the better
The goal - render ‘above-the-fold’ content in
one roundtrip to the server (~14kb)
15. Asynchronously loaded assets are not render-
blocking
Defer the remaining CSS using an async loader,
such as this one by Filament Group
https://github.com/filamentgroup/loadCSS
16. However, that means introducing a dependency
on some render-blocking JavaScript
If you load CSS asynchronously you will need to
deal with FOUC (Flash of Unstyled Content)
17. IMO keeping it simple is often best
Unless your CSS is rather large, just load it
normally - the browser will cache it
18. In my case my minified CSS was under 10KB*, so
I inlined the whole lot!
*10KB is the recommended maximum size for
inlined CSS
22. Originally I had rather lazily used the standard
font loading script
<script src="https://use.typekit.net/vbu2ffi.js"></script>
<script>try{Typekit.load({ async: true });}catch(e){}</script>
23. However, Google does not like this
“Eliminate render-blocking Javascript and CSS
in above-the-fold content”
24. The solution?
Use an async font loading script
This means the browser can carry on rendering
the page without waiting for the fonts to load
25. What about FOUT (Flash of Unstyled Text)?
Typekit adds helper classes to the <html> tag
You can hook into them to initially hide, and
then show text once the fonts have loaded
.wf-loading
.wf-active
27. Google recommends:
If the script is small you can inline it to reduce
network request latency
Larger, external scripts should be loaded
asynchronously so as not to block DOM
construction
28. In my case the scripts used were small and non-
critical
So I inlined them at the bottom of the page
31. You’ll have minimal gains in terms of bytes
saved, but it’s one more thing ticked off the list
It can be tricky to do, especially on dynamic
sites, but on simple, static sites it shouldn’t be a
problem
On my site I used a Ruby gem, called minify-
html - job done!
37. • Inline critical CSS, defer the rest (or not)
• Use an async font loader
• Remove render-blocking JavaScript
• Minify HTML
• Enable Gzip compression on the server
42. Why not 100/100?
“Leverage browser caching”
Unfortunately I have no control over external
resources and their cache headers:
http://use.typekit.net/vbu2ffi.js
http://www.google-analytics.com/ga.js