CSS spinners & other spinners

Considerations

• 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 CSS & javascript page with the same images on screen (even one less)!
  Now Google PageSpeed Insights come with a speed 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).
• Images (and other page ingredients) can be loaded in advance, on a page before (with a deferred loading); see W3C specification and CSS-tricks article Prefetching, preloading, prebrowsing.
• Serve responsive images for different devices; see Mozilla article 'srcset' and 'sizes'.
• 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.

Aside

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).
- The only way seemed to be a "hard delay" with a javascript setTimeout for the start of the animations of the spinners (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.

• See for this Blink phenomenon (and a Firefox anomaly) also the separate Multiple CSS Animation Browser Test page.