30

In CSS we can use several different methods to define a color:

  • Color word: red
  • Hexadecimal: #FF0000
  • Red/Green/Blue channels: rgb(255, 0, 0)
  • Hue/saturation/lightness: hsl(0, 100%, 50%)

I do realize that using named colors is not a good idea, as different browsers have their own idea of what aquamarine looks like.

Ignoring alpha channel and browser support, are there any differences performance-wise between these 4 methods?

If we were trying to squeeze every last bit of optimization out of our CSS, which one would be preferred, if any? Are the color values converted to a specific format internally, or does the performance of it depend on anything else (like which rendering agent or browser is used)?

Looking for a "technical" answer if possible, references appreciated.

Wesley Murch
  • 101,186
  • 37
  • 194
  • 228
  • 3
    Really? I didn't know that using named colors was a bad idea. I would have assumed that aquamarine equated to some numeric value on all browsers on all OSes. Is my assumption incorrect? – Marvo Jul 23 '11 at 00:08
  • Relevant http://stackoverflow.com/questions/1171422/are-there-any-good-reasons-for-using-hex-over-decimal-for-rgb-colour-values-in-cs – andyb Jul 23 '11 at 00:09
  • @andyb: Thanks for the link. Those answers are a bit loose and non-technical though, kind of geared in another direction, like "What's easiest for me to type or understand?" – Wesley Murch Jul 23 '11 at 00:12
  • @Wesley: Yes, I've just gone though them in a bit more detail and agree. A relevant question but not an answer. jQuery only returns RGB values http://stackoverflow.com/questions/1740700/get-hex-value-rather-than-rgb-value-using-jquery so maybe RGB is the approach to save on any conversion hit? – andyb Jul 23 '11 at 00:27
  • 1
    On the first load (not cached) the shortest will be faster: less characters = less kb. So in your example the winner will be `red`. Note that for example `fuchsia` will be beaten by `#f0f`. – Knu Jul 23 '11 at 06:30
  • 2
    Coming back to this now (2 years later) I think it is a silly question... – Wesley Murch Aug 16 '13 at 19:55
  • 3
    Performance optimizations can really get you to mad levels :D – cschuff Feb 06 '14 at 20:12
  • @WesleyMurch: I pretty sure you're mistaken in your theory that *"`different browsers have their own idea of what aquamarine looks like`"*. For example, [`Aquamarine`](https://www.color-hex.com/color/7fffd4) is hex `#7FFFD4` which is `rgb(127,255,212)` and so on. Different *screens* may show colors differently but that has nothing to do with using the name. While it might save a couple bytes **There will be no *noticeable* performance loss** from using named colors (but you'll have the advantage of knowing *which* color it is). You may as well remove LF's & spaces (also not recommended) – ashleedawg Sep 24 '19 at 01:51
  • @ashleedawg Yeah I was smoking crack when I wrote this, in my third year of web design, which I no longer do. I wish I still had "problems" like these... <3 Regardz – Wesley Murch Sep 25 '19 at 15:07

6 Answers6

18

Here are the results including color names, short hex, hex, rgb, rgba, hsl, and hsla. You can run the test yourself here.

Performance Test Results

nu everest
  • 9,589
  • 12
  • 71
  • 90
  • 2
    How does this benchmark relate to the question? It says how often a value can be asigned and evaluated by JavaScript. It doesn't say anything about actual render times, or does it? – lampshade Sep 20 '19 at 10:22
  • @lampshade is right. No correlation between JS creation of colors and rendering of colors in the browser window. – Quoting Eddie Dec 24 '19 at 08:45
17

If we assume a modern browser making full use of the GPU then the internal color representation will be RGB floats. Ignoring the color name - which is probably just a map to hex anyway - I think that hex and channels will be the fastest. HSB will undoubtedly be the slowest, as the conversion from HSB to RGB does require some work - about 50 lines of C code.

However, I think that for the purpose of CSS, this is a completely irrelevant question. Even for HSB to RGB the amount of work on one color will be totally trivial. By way of support for this, I have several programs - including those running on mobiles - which do color manipulation at a per-pixel level on largish images where I am doing RGB->HSB->(some manipulation)->RGB. Even performing this operation 100,000 times on an ipad only results in a delay of a couple of seconds - so on this relatively slow platform, I think your typical worst case conversion can be safely assumed to take less then 0.0001 seconds. And that's being pessimistic.

So just use whatever is easiest to code.

ADDED: to support the don't worry about this option. Internally a GPU will manipulate colors as an array of floats, so in C terms

float color[4];

or something similar. So the only conversion being done for the numeric options is a simple divide by 255.

On the other hand conversion of HSB to RGB takes considerably longer - I'd estimate, from having written code to do it, about 10 to 20 operations. So in crude terms HSB is considerably slower, BUT 20 (or even 20,000) operations on a modern GPU isn't worth worrying about - it's imperceptible.

Prusprus
  • 7,987
  • 9
  • 42
  • 57
Cruachan
  • 15,733
  • 5
  • 59
  • 112
  • 3
    I figured someone would tell me not to worry about it, I tried to ward off those type of comments. I also have a curiosity about it, so it's not totally irrelevant, and an accurate, concrete answer *must* exist, right? So are you saying Hex is converted to RGB, and that RGB is probably the fastest? And I agree about the color name, I think we can assume it is not the winner :) Appreciate you sharing your experience. – Wesley Murch Jul 23 '11 at 00:26
  • 1
    @WesleyMurch, it really isn't worth worrying about, I think you're totally missing how fast CPUs are. A Intel i7 for example runs at ~150,000,000,000 operations per second. You only see significant issues with this sort of thing if you're compounding by looping over code. A few items in a CSS file is just irrelevant, by several orders of magnitude. – Cruachan Jul 23 '11 at 00:46
  • 2
    Just to be clear, I fully understand that the performance difference is *beyond* trivial, you really don't have to convince me, but I have a mind that is curious about how these things work and wanted to know more about it. I didn't really find any info on Google, it's kind of a niche topic I guess. Once again, thanks for sharing your knowledge. – Wesley Murch Jul 23 '11 at 00:59
  • 1
    NP. I would say that the comments about the amount of bytes going over the wire are much more worth of consideration (but even there unless you have a large css file I doubt it'll cause any measurable issues) – Cruachan Jul 23 '11 at 08:28
  • Please also mind that most sites have only a distinct set of different colors. Those are covered only _once_ and then cached. – Quoting Eddie Dec 24 '19 at 08:49
9

I used the same tool from jsperf.com that the others did, and created my own test for different color formats. I then ran the test on IE11, Edge17, FF64 and Chrome71 and gathered all results in a compact excel spreadsheet.

Top three are green, bottom three are red, best and worst are bold.

I don't know why Chrome is so prone to named colors format, but it made me repeat the test many times with the same and different parameters. Results remain constant.

You cannot get conclusive results of any one format being the absolute best, but my conclusion is as follows.

I will keep using hex over named, lowercase over uppercase and start using short over long hex when possible.

Feel free to update results if they change with new versions of browsers.

Community
  • 1
  • 1
s3c
  • 1,481
  • 19
  • 28
8

Typically, css optimization is all about minimizing the number of bytes going over the wire. The hexadecimal colors tend to be the shortest (in your example, #f00 could be used instead of #ff0000).

I realize this isn't exactly answering the question you've asked but I haven't seen any browser tests which attempt to measure how different color representations affect rendering speed.

Ken Browning
  • 28,693
  • 6
  • 56
  • 68
  • 2
    It's actually not only the amount of bytes. Different "bytes" (functions) have a different effect on performance. Take e.g. the blur effect: not many bytes but very CPU/GPU intensive. – Quoting Eddie Dec 24 '19 at 08:43
6

I too was curious about this (it's a Friday afternoon). Here's a JSPerf for the various CSS colour methods:

http://jsperf.com/css-color-names-vs-hex-codes/18

cloakedninjas
  • 4,007
  • 2
  • 31
  • 45
2

Edit: Each process has to get down to a binary value for r, g, and b. Hex and rgb bytes are already set up for that, so I guess they might actually be roughly the same speed. The rest have to go through a process to reach a hex/rgb value

#FF0000 = memory values of: 1111 1111 0000 0000 0000 0000

rgb(255,0,0) = memory values of: 1111 1111 0000 0000 0000 0000

Both cases are most likely stored in 3 int variables. So the real question is, which is faster to process into binary values for these integers? HEX or DEC? I think HEX, but I can't back that up. Anyhow, the code just takes the binary values of these variables.

Nick Rolando
  • 25,879
  • 13
  • 79
  • 119
  • Any reference or slightly more detailed explanation would be great if you have it. I barely understand how the hex to binary translation would be different from another method, especially when it comes to rendering a color, which is arguably better represented in one of the other formats. – Wesley Murch Jul 23 '11 at 00:15