Using Font Smoothing to avoid blinking text rendering

Hi guys,

Wondering if somebody can help.

If you look at the header on the homepage of my website, you’ll see the text blinks when you open it with Safari. No issue with Chrome or Firefox.

If you click on the Online Training link, you’ll see a very similar version of the header with no blinking.

Here is the technical info you need:

Thanks for your help.


Hi there,

I’ve isolated the cause. The arrow under the “See more” text has a little animation on it, called “arrow-hop” which you can find in the “Interactions” list.

When I turn it off, the blinking stops. But I’d prefer to have it on.

Any suggestions?

It doesn’t blink on my Safari.

Elements having glitches are often provoked by animated elements overlapping them. Make sure your blinking element has a higher z-index value than the animated one, to begin with. Does it fix the glitch?

Thanks Vincent. I think z-index is the cause alright, but I can’t find the z-index setting for the nav elements. (I can see it for the arrow, but not the nav).

Not sure why it’s not visible…

Ok, managed to find the z index. But it hasn’t changed anything :frowning:

Throw this in your head tag. Fixes all the weird text rendering that happens in safari.
<style> body { -webkit-font-smoothing: antialiased; } </style>


Aw, man. That’s great. Thanks a million. Problem solved :slight_smile:

Sure, same thing bothered me so now I use that snippet in all my sites.

1 Like

I use that too. I’m sometimes concerned with the effects on performances. I did a quick search.

Found this:

And found a discussion where Marc Edwards from Bjango says a few things. As this person extensively test these things, I totally trust is jugement. here’s the quote:

Marc Edwards

“Font smoothing on large amounts of text requires more CPU”

Are you talking about sub-pixel antialiasing (-webkit-font-smoothing: subpixel-antialiased;) or standard antialiasing (-webkit-font-smoothing: antialiased;)? Sub-pixel antialiasing requires more CPU than standard antialiasing.

Sub-pixel antialiasing is not possible in a lot of situations:

• iOS doesn’t use sub-pixel antialiasing anywhere, because the display orientation changes, and the sub-pixel order and orientation changes with it. That breaks the trick to gain extra resolution.

• Sub-pixel antialiasing typically requires an opaque background to be composited on.

• Sub-pixel antialiasing is less important on high DPI displays.

Further discussion: iOS and Android don’t have sub-pixel antialiased type. Microsoft’s Surface doesn’t seem to either (I haven’t seen any screenshots of Windows 8’s Metro UI with it). So the entire future of mainstream computing is going to be high DPI, but possibly not contain sub-pixel antialiased type.

If you’re grumpy about things not being sub-pixel antialiased, the future is looking pretty bleak.

My advice: Move on.

This battle has been fought and won. Faster performance and devices that can be used sideways and upside down trump slightly better text rendering.

I’m not sure of the performance hit for standard vs sub-pixel antialiasing, but I’d assume it’d be roughly 3×, as there’s three channels of rendering an compositing verses one. I’d love to hear from a type-rendering engineer on the topic though.

Discussion from here:

And a Bjango article on sub pixel rendering:

1 Like

Cool article but to be honest is CPU really an issue anymore? My sites load fine on my old macbook which is slow as hell. I had used subpixel before but it did nothing, so i switched to regular and it fixed my issues. It’s worth it to me regardless of performance.

1 Like

Awesome! Shouldn’t this be baked into Webflow?

1 Like