This isn't so much an issue as a log of performance improvements to the site.

Test setup

WebPageTest

Node: Australia, EC2
Browser: Chrome
Connection: Cable
Number of passes: 3
Type: First and repeat view

Lighthouse 2.0

Running Chrome's new Audit feature: Lighthouse.

WebPageTests

Lighthouse Tests

Hi nzruby,

I'm working on a fork that'll add ServiceWorkers, but these ServiceWorkers won't work if the site is not served over SSL/TLS.
Who can I get in contact with to organise this certificate? Or can someone please take a look at getting a free certificate through LetsEncrypt.org?

Thanks!
-Shaun

Hey @mermop

You've been quiet - hope you're doing OK!

If the build_cleaner script we added is not working as we intended, it could be because webpack uses the .tmp directory for handover to Middleman. That directory might still have the font-awesome files lying around.
If you delete the .tmp directory before a build you should get a nice clean build.

-S

During a build and deployment, we should set the following caching policies in config.rb

Asset Cache-Control, max-age = years
HTML Cache Control for HTML: max-age 5 minutes
Individual Cache Control: service-worker.js max-age: 0, must revalidate.

So that we can store environment variables securely without making it harder for people to deploy the website, let's think about bringing in Travis or something.

Maybe we could even.. write a test??

An audit is required, but it looks like the following files are included in the pre-cache, and they might not used by the client:

Fonts:

/assets/public/fonts/fontawesome-webfont.eot (Not sure where theses fontawesome files come from - remnants of a build folder?)
/assets/public/fonts/fontawesome-webfont.ttf
/assets/public/fonts/fontawesome-webfont.woff
/assets/public/fonts/fontawesome-webfont.woff2
/assets/public/fonts/fontawesome-webfont.svg

/assets/public/fonts/OleoScriptSwashCaps-Regular.woff2 (This is now a logotype on the homepage)
/assets/public/fonts/YoungSerif-Regular.woff2 (Not used)

Images:

/images/sponsor-logos/sponsor_addressfinder_770.png (Not used)
/images/sponsor-logos/addressfinder.png (Not used, was reformatted)
/images/sponsor-logos/boost-horizontal.png (Not used)
/images/sponsor-logos/sponsor_boost_500.png (Not used)
/images/sponsor-logos/sponsor_boost_770.png (Not used)
/images/sponsor-logos/sponsor_boost_tall_770.png (Not used)
/images/sponsor-logos/boost-tall.png (Not used)
/images/sponsor-logos/icelab.svg (Not used)
/images/sponsor-logos/sponsor_loyalty_500.png (Not used)
/images/sponsor-logos/loyalty.png (Not used, was reformatted)
/images/sponsor-logos/sponsor_optimal_workshop_770.png (Not used)
/images/sponsor-logos/optimal.png (Not used, was reformatted)
/images/sponsor-logos/sponsor_rabid_770.png (Not used, was reformatted)
/images/sponsor-logos/sponsor_rabid_500.png (Not used - we should use this on the scholarships page)
/images/sponsor-logos/sponsor_storypark_500.png (Not used - we should use this on the Childcare page)
/images/sponsor-logos/sponsor_storypark_770.png (Not used)
/images/sponsor-logos/sponsor_the-last-pickle_770.png (Not used)
/images/sponsor-logos/the-last-pickle.png (Not used, was reformatted)
/images/sponsor-logos/sponsor_trineo_500.png (Not used)
/images/sponsor-logos/trineo.png (Not used, was reformatted)
We use gembirb-up.svg as the footer logo, but these seem to be copies:
/images/gembirb.png (Not used, source image?)
/images/gembirb.svg (Not used, source image?)
/images/kiwirubylogotype.svg (Not used, source image?)
/images/rubylogo.png (Not used, source image?)
/images/sirocco.gif (Not used on the site - maybe externally?)

There are a few choices we could make with these files after we've audited them:

• move these files outside of the source folder, so we keep them as originals, but they don't get published to the website
• we delete them
• we add their patterns to the offline_cache_ignore.json data file so that the service worker ignores them

The site should g-zip all content, excluding PNGs and JPGs.
SVGs, Icons, HTML, JS, CSS, XML, Text and JSON can all be gzipped during the end of the build process.

Hi! 👋

I thought the use of webfonts on the site was a little out of control, so I did an audit and found the following:

1. It looks like Work Sans is being used for most of the site: >99%
2. Source Code Pro is intended to be used for sponsors names in the sponsors partial, if the sponsor.show_name boolean is true. But none of the sponsors are represented as such.
3. Source Sans Pro is only used once in the .hero_date element on the homepage. This could be replaced with a suitable cross-browser font, saving us 2 blocking HTTP requests and ~15KB.
4. YoungSerif and OleoSwash are declared, imported, make 1 blocking request each, but are never used.

Recommendations:

1. Leave Work Sans as is.
2. Remove Source Code Pro
3. Replace Source Sans Pro with something like Droid Sans or sans-serif
4. Remove YoungSerif and OleoSwash

Next steps:

We could see a healthy improvement in rendering performance if we remove these fonts. I'm happy to do the work with your blessing :)

-S

Add a link to the youtube videos

Turbolinks should be responsible for calling the mobile menu script. i.e. the mobile menu script mustn't self-execute, else there'll be two click handlers competing with one another.
⚠️ @mermop ⚠️

Hi! 🖖

Here are some things I could do for the site, if needs be:

• Wrap the Google Analytics script in a DoNotTrack check. Being nice web neighbours.
• Incorporate the GA Script in the global JS. Doing so reduces the HTML weight, and adds cacheability to the script that invokes GA.
• Add Schema.org metadata where it counts.
• CSS audit - clean up unused CSS, break it up into partials. See: #72
• Expose sponsors as independent URLs
• Expose speakers as independent URLs
• Expose the venue as an independent URL

Tick all those you'd like me to tackle :)

-S

Show a banner at the top of the page linking to 2019

Would it be possible to consider alternatives for the Google Maps instance on the homepage, please? The reason I'm pushing for an alternative, is that come ServiceWorkers, we want something we can cache. A static image would be great to cache.

We could:

• Link to a venue page.
• Replace the inline Google Maps instance with a stylised map.
• Replace the inline Google Maps instance with a Google Static Maps image.
• Look at lazy-loading the inline map using the new IntersectionObserver, or at least delaying the load till last.

Having a static image with a link to a Google Maps URI would mean a handset would open the Google Maps app if it was installed.

What do you think @mermop?

As per discussion in #30 and #45

We should fingerprint assets (index.css and index.js in particular) to prevent overzealous caching messing with deploys

Hi! 👋

The main menu is repeated, once for mobile, the second for larger screens.
With some breakpoint-related CSS, we can shift one menu from mobile mode to tablet mode pretty easily.

If you're happy with that plan, I'll look at doing the required changes in a PR.

-S