Introducing rokka stack expressions

  • Christian Stocker

Stacks in rokka were already a powerful way to abstract away the actual definition of how images should be rendered. It frees up the frontend implementation of knowing what's the best way to deliver those images, it just has to know the appropriate stack name and keeps those URLs short and easier to remember.

Now, we made them even more powerful with expressions. Expressions can override a value depending on other values. What is this good for? The major use case currently is that with higher resolution screens, images can get quite large when you send them in the right size. But they don't need a very high compression quality to still look good as on non-retina screens. This can save a lot of kilobytes in your requests. See for example this blog post by for some comparison.

Until now you either needed two different stacks to achieve this (and the frontend implementation had to know, when to use which one) or add way too many dynamic options to the URL (and again, the frontend had to know, which are the right ones).

Not anymore, rokka expressions to the rescue. A stack definition to define a lower jpg quality for retina images would look like the following:

  "operations": [
      "name": "resize",
      "options": {
        "width": "500"
  "options": {
    "autoformat": true,
    "jpg.quality": 80,
    "webp.quality": 80
  "expressions": [
      "expression": "options.dpr >= 2",
      "overrides": {
        "options": {
          "jpg.quality": 50,
          "webp.quality": 50

It basically says, use a jpg and webp quality of 80, except if DPR is set to 2 or more, then use 50. And all you're frontend has to do is to request for non retina images and for a DPR of 2. Rokka will then do all the magic.

You can put all that in srcset enabled img tags for making the browser decide, what it actually needs.

<img src="" 
     srcset=" 2x">

Addendum I: We're currently working on template helper classes for the rokka php client and also a rokka twig implementation for easier integration of rokka and such features into your new or existing projects.

Addendum II: We also introduced a short_hash for all new images on rokka last week. Makes your image URLs even shorter, eg. instead of one with a 40 char long hash. You can use that short hash for all render and API operations on rokka.

Addendum III: We're also working on support for HTTP Client Hints for even more magic in delivering the right image. Watch this space for more.

Tell us what you think