Recording & compressing short screencasts on Windows

Tools I use

  • CamStudio with the lossless codec for screen recording
  • ffmpeg
  • a scripting environment with shell access (I chose node.js) for batch converting

My process

  1. Capture video using Camstudio

    I choose to record 1 window as my region, and compress with the Camstudio lossless codec.

  2. Use ffmpeg via a node.js script to batch convert videos

    This turns them into something that can be played in a web browser

    var fs = require('fs'),
        util = require('util'),
        child_process = require('child_process');
    var shellCommand = 'c:\\ffmpeg\\bin\\ffmpeg.exe -i %s -codec:v libx264 -profile:v high -preset slow -b:v 500k -maxrate 500k -bufsize 1000k -threads 0 -y %s';
    fs.readdir('./', function (err, paths) {
        paths.forEach(function (path) {
            // TODO - only convert *.avi files
            var command = util.format(shellCommand, path, path.replace('.avi', '.mp4'))
            var child = child_process.exec(command, function (error, stdout, stderr) {
                console.log(path, err, stdout, stderr);

    I base my settings on Jemej’s ffmpeg tutorial. The quality and framerate are low since I usually record things that don’t move much like terminal windows.

Ideas for improving

  • this is dumb – it runs every .avi file in the folder through ffmpeg whether it needs or not.
  • are there smarter ways to use all the cores of my CPU?
  • what about watching for .avi file changes/additions with gaze and encoding new .avi files as soon as CamStudio saves them?

#towebperf – performance @ Shopify

Bryson Gilbert presented techniques his team uses on Shopify’s main marketing site,


  • 10ms goal for generating pages on the server with Ruby on Rails
    • no database
    • no CMS
    • All content is in fast loading, versionable flat files.
  • marketing assets (icons, images, css, style guides) are stored in a Ruby gem and shared across different Shopify web properties (admin areas tools, internal tools, blogs etc).
    • optimize once, use anywhere
  • HTTP requests – in general, each page loads 1 common js and css file (shared across all pages), and sometimes 1 page specific js and css file. 3rd party scripts are loaded if needed
    • the team is investigating inlining the page specific code – it is usually small, and could save 2 HTTP requests
    • some ab testing tools require blocking js to manipulate copy and images before gathering results. This sucks, but there is no choice
    • load as much 3rd part JS asynchronously as possible
    • lazy load images with lazysizes
  • responsive images – using a Ruby gem to make implementing img srcset attribute and lazy image loading easier across all web properties
  • icons – using inline .svg, no icon fonts
  • workflow – set up a Git precommit hook to run imageOptim on images so that unoptimized images never even get into the Git repo
  • fonts – just using @font-face, no inlining
    • just serving woff and woff2, best file size and adequate browser support for their audience (people on slow connections also tend to have browsers that don’t support woff, so they don’t get help up downloading fonts)
    • not optimized yet.
    • this is the hackiest part of optimization
  • going HTTPS only did slow down the site slightly


  • SpeedCurve for monitoring performance, relating deploys to changes in performance
  • NewRelic RUM for checking on performance around the world.
  • Shopify is getting into Performance Budgeting by setting relative goals.


  • HTTP2 will change how pages are optimized
  • resource hints will be helpful, but not 100% controllable
  • Better font loading is coming

Building a culture of performance

  • Sharing knowledge with documentation
  • Weekly frontend dev meetings to discuss failures & successes
  • Working performance into discussions early on in design process (can help with photo/image selection)

Other fun stuff (some from Barbara’s new book

  • Etsy publishes quarterly website performance reviews
  • Performance is respect for users. Optimized for their perspective, not your s. Real User Monitoring.
  • think about the 14kb rule
  • use inline CSS for above the fold content
  • loads js as late as possible
  • Latency on mobile – remember cell phones have to initiate a connection to a cell phone tower that is rarely a consistent distance away.
    • JS and AJAX eat mobile batteries fast

Fixing SSL errors on Android Chrome with RapidSSL

Your ‘Order: xxxxxxx Complete’ email from RapidSSL includes links to a bunch of intermediate SSL certificates. Will you install the right one? I have seen installing the incorrect intermediate SSL certificate into the certificate chain cause Chrome on Android to declare a site insecure and block users from accessing it, while every other browser accepts it.

This tool helped me fix the issue: It pointed out that the wrong intermediate certificate was in the chain, and directed me to download a RapidSSL SHA256 CA - G3 certificate. I chained that with my server’s SSL certificate, and my Android issue went away.