Chrome has been my default browser for many years now, but I’ve been thinking that my familiarity with just one browser has become a problem. If I tend to design for a single browser, then I’ll start to make assumptions that those features are available for everyone. Then I’m likely to miss important differences between browsers which could introduce bugs into the codebase or influence the amount of time I spend designing a feature.
I’ve started to call this problem “Chrome Bias”, and over the past week, I decided I would do something about it by switching to Firefox. This way I could figure out what’s new in one of the most popular web browsers out there. But! While I was running this little experiment of mine, I found three Firefox features that you might not know about if you suffer from extreme Chrome Bias like I do.
I think these Firefox developer tool features are pretty nifty:
Theming the Developer Tools
I didn’t know that you can set the theme of the Developer Tools in Firefox. That is particularly helpful for me when I want to work on something at night and can configure the theme to dark:
Firefox’s font tab might not be new but it certainly is to me. On the far right you can select the tab and see the type info for whichever element you’ve selected:
It’s pretty neat that it tells you not only how to use that @font-face rule, but also the location from which the font is being requested as well. My favorite button here though must be the “See all the fonts used in the page” button which sits in the bottom-right hand corner. Once you’ve clicked that you can see every font-family that’s been declared in the stylesheet that’s served to the page:
I can see that being super helpful in larger codebases where you might accidentally have lots of fonts being declared inconsistently.
After you’ve hit the ‘Performance’ tab and refreshed the page, you’ll see a waterfall of every resource that’s been requested. But did you know that you can see this data in the form of a graph, too? Here’s how that works:
This is a great tool to identify bigger problems in performance—perhaps you have a massive stylesheet being requested by the browser, and from here you’ll be able to see the scale of the problem faster.
Here’s the thing: the more we experience how other browsers work, the more we learn about how different users experience our websites. Understanding how developer tools differ was useful in this instance, but learning about how unfamiliar browsers look and feel is enlightening as well.
For the next step in my experiment, I want to try out more mobile browsers because I imagine the differences between them are even larger than those between desktop browser apps.
What tricks have you learned from your non-regular browser lately?