In my opinion: spinners are no page content, so the use of them has to be avoided !
Ask yourself the question: 'Is a spinner on the page really needed? Or are there other possibilities for a good user experience?'
As a temporary feature, a spinner must not draw a lot of attention: if needed, keep them simple !
Spinners only for emergency cases!
For spinners in general (CSS-rotating images, CSS-only spinners, animated gif's, etc.), I should advise: try to avoid them by speeding up the page.
Often images can be optimized to decrease the image size and/or increase the compresssion: that can give a dramatic faster download time.
On the pages before are big size images used as demo; exception: the Conclusions page. In that
page the images are optimized (in px size, and some from uncompressed png to jpg with lossless compression; tool:
tinyjpg.com). For instance: the landscape photo on thre Conclusions page is 183kB (instead of 10MB), the
download of all page elements is finished in around 0.65 à 0.9 sec (on PC, fast connection); that was ... 8 à 8.5 sec for the
Now Google PageSpeed Insights come with a
score 100 out of 100.
Images can be combined in CSS-sprites, since the invention of background-images still in use,
to save http-requests.
Keep images for normal use on screen and for print quality separated (for example: print quality only as click-able download option, or with an
@media print rule).
Combine (or just split !) blocking
script-files and CSS-files, make deliberate choices for where to place them in the HTML
Lots of other Need for Speed techniques, see for instance the
Loading Performance articles on Google Developers.
Note: in the illustration on top of this page I embedded the spinners in a <div id="scaler">, with a combined animation
of the transform: scale(..) and the positioning left: ..%; top: ..%;.
Firefox and even IE-11 support this without grumbling. Blink (Chrome and Opera) apparently has a bug and can not handle this: result is a blurry spinner. The opacity variations
don't have influence on it.
It looks like Blink is in a hurry and takes the first transform: scale(.1) of the spinner as base for enlarging later on, with a
pixelated thing as outcome.
But without animation of the spinner Blink is performing as expected !
While I didn't want to explore another embedding div around, I didn't succeed in finding a proper CSS work-around for Chrome & Opera which was appreciated
by the other browsers.
A CSS-delay for the animation of the spinners didn't help ! (nor alternative positioning with margins or translates).
(see source code of this page). To obfuscate the initial not spinning spinners, an ease-in style is provided. If the system is
running in this way (second and further runs of the spinner moves), everything is fine and they are spinning already when appearing at the bottom.