Fixing slow Firefox loading when using Pi-Hole

I run Pi-Hole to prevent clients on my network from loading dangerous or gross things like advertisements or tracking scripts. This normally works great: it functions on all devices without requiring configuration and I don’t need to think about it too often.

I’ve also been using Firefox a lot more often lately, partly because Big Sur introduced a lot of Safari regressions and sites like Twitter are broken regularly, and partly because I like the features it’s coming out with like HTTPS-only mode.

Unfortunately, Firefox and Pi-Hole do not play nicely together when it comes to certain websites. For example, when loading sfchronicle.com several of its trackers have performance issues:

A graph of timings for a network request. The first is 'Blocked' with 5.11 seconds. After this, staggered after Blocked, is 'DNS Resolution' which shows a 1.01 second timing. The rest are 0 seconds: connecting, TLS setup, sending, waiting and receiving.

When Firefox comes across a host which resolves to 0.0.0.0, it appears to have some kind of internal retry mechanism that, combined with HTML’s sequential loading of scripts, causes a cascading set of delays making loading take an extremely long time.

Fortunately, Pi-Hole’s behavior of returning 0.0.0.0 for disallowed hosts is configurable. Changing its BLOCKINGMODE to NODATA changes the resolution behavior from:

$ dig +noall +question +answer secure.quantserve.com
;secure.quantserve.com.		IN	A
secure.quantserve.com.	2	IN	A	0.0.0.0

to:

$ dig +noall +question +answer secure.quantserve.com
;secure.quantserve.com.		IN	A

Instead of providing an IP address, the response we get is instead that there are no A records for the domain, and Firefox gives up a lot faster, taking a few milliseconds instead of a few seconds. The Pi-Hole documentation on blocking modes provides a caveat:

…experiments suggest that clients may try to resolve blocked domains more often compared to NULL blocking…

The default blocking behavior (NULL) is returning 0.0.0.0. I have not come across any issues with this change, but I also don’t think I’d notice if DNS requests drastically increased on my network.

This doesn’t resolve all of the performance issues on the SF Chronicle in Firefox. Even using a non-Pi-Hole DNS server shows significant loading delays compared to Safari. This, at least, makes it painful instead of frustrating. As an aside, I am resentful that I’m paying $12 per month for a website that wants to inject the scummiest of Taboola-level ads on me.

Back to Safari

Chrome arriving on Mac was an amazing upgrade in the normal browsing experience. However, Safari’s new features and battery savings in Mavericks prodded me into giving it another try.

A few utilities made it a lot easier to use Safari:

  • YouTube5 enables many YouTube videos that would otherwise not work.
  • command-number-tab can power using ⌘1, ⌘2, etc. for switching tabs.

Update 2015-06-14: Safari in OS X 10.11 adds a preference for doing the ⌘1..N shortcut without needing a hacky extension.

There are also a few really important shortcuts to pick up fast:

  • ⇧⌘\ opens the “tab expose”; you can then swipe left and right or use the arrow keys to switch tabs. (There’s a gesture, too, but two-finger pinch-out isn’t easy.)
  • ⇧⌘R opens the reader view, which seems better than I remember. It saves scroll positions when you click links, and reformats text impressively.
  • ⇧⌘L opens the bookmarks sidebar, which I’ve found quick and easy.

Zooming is really clean: like in iOS, you can two-finger pinch to fluidly zoom in; and two-finger tap will intelligently zoom to fit the content.

I’ve still itched for Chrome a few times, especially when trying to sign into a second session on a webpage or use it logged out: I end up using Chrome’s incognito windows fairly often. These happen fairly often in my workflow.

Overall, I think Safari suits my needs pretty well without needing to bother with Flash or overwhelming extension use like in Firefox. It uses less power than Chrome, and just feels faster.

Custom Kindle Paperwhite fonts

I thought jailbreaking would be required to install custom fonts on the Kindle Paperwhite, but a recent Kindle firmware update silently added support for accessing custom fonts.

This writeup walks through installing custom fonts on a few devices. A few simple steps will get you through it:

  1. Mount the Paperwhite.
  2. Create the file USE_ALT_FONTS in the mounted volume.
  3. Create the folder fonts in the mounted volume, and add fonts consisting of all the following (where Font is the name of your font):
    • Font-Regular.ttf (.otf is also supported for the files)
    • Font-Bold.ttf
    • Font-Italic.ttf
    • Font-BoldItalic.ttf
  4. Restart the device (Hamburger > Settings > Hamburger > Restart)
  5. You may need to clear the font cache by searching on the home screen for ;fc-cache and then restarting.

You can find your Mac’s fonts in one of a few places:

  • /System/Library/Fonts
  • /Library/Fonts
  • ~/Library/Fonts

Although I love reading in Georgia, it doesn’t render wonderfully on the Paperwhite, so the hunt is on for better typography.

Preventing Rdio from using discrete graphics

Rdio requires the discrete graphics card on systems which support dynamic switching. This is annoying, since playing audio shouldn’t require intense graphics.

To get around this limitation, we can update the Rdio app’s Info.plist to inform the system that it supports the integrated card. We can accomplish this with the following command:

defaults write /Applications/Rdio.app/Contents/Info.plist NSSupportsAutomaticGraphicsSwitching -bool YES

To revert back to forcing the discrete card, we can remove the key:

defaults delete /Applications/Rdio.app/Contents/Info.plist NSSupportsAutomaticGraphicsSwitching

Incidentally, gfxCardStatus is an excellent tool for monitoring graphics card changes and manually switching between cards.