Use Cloudinary’s auto-breakpoint generation, somehow?

[eeeps]

The min_size / max_size/ steps preset config parameters are cool.

What would be really cool is to somehow use Cloudinary’s responsive breakpoint generation logic to dynamically figure out the number of steps based on ideal filesize jumps. I'll think about/ask if there are good ways to do this...

[nhoizey]

It would be great, indeed.

I'll try to find a way!

[eeeps]

So I asked about this and the response was:

The breakpoints should work with the explicit API that can be used to prefetch the URL while still using fetch and not upload. Another option is to use the lazy approach w_auto:breakpoints:json

Here’s the link to the explicit API docs
http://cloudinary.com/documentation/image_upload_api_reference#explicit

Some other helpful nuggets:

• the public_id of a fetched image is its URL
• if you want to go “lazy”, the documentation on w_auto:breakpoints:json is here (under the "Breakpoints generation delivery URL" subheading)

[eeeps]

Hopefully I’ll find some time over the next few months to work on this. In the meantime...

The cleanest API for this would be a single new optional side-wide parameter, named something like bytes_step.

We can use that + the existing min_width, max_width and steps¹ parameters to GET this URL (somehow, somewhere):

"https://res.cloudinary.com/#{settings["cloud_name"]}/image/#{type}/#{transformations_string}w_auto:breakpoints_#{min_width}_#{max_width}_#{bytes_step}_#{steps}:json/#{image_dest_url}"

That will return something like:

{"breakpoints":[100,473,751,1000]}

That’s easy enough to iterate over to build a srcset, here, if bytes_step is defined.

Big unanswered questions which I need to brush up on my Jekyll to answer—

• how in the heck and where in the heck do we store the breakpoints?
• how can we check to see if we’ve already stored the breakpoints, and if we haven't, GET them?
• is it even feasible to make these HTTP requests as a part of the build process without making build times unacceptably slow?

---

¹: steps becomes Cloudinary’s max_steps — so you’ll get that number of resources or fewer. If steps is low, we’ll make bigger jumps between resources than the bytes_step, but those jumps will be equal(ish), byte-size-wise.

[eeeps]

I've been fooling with this. Hopefully I'll have some code to show soonish, but I'll attempt to answer my own questions:

• how in the heck and where in the heck do we store the breakpoints?

In a Jekyll data file! Breakpoints stored here should be readable from within the plugin via site.data.breakpoints (or whatever); we can write any new data back out in a site post_render Hook.

• how can we check to see if we’ve already stored the breakpoints, and if we haven't, GET them?

if !(site.data.breakpoints) then get_w_auto_breakpoints_url_and_store_result(image_url) end

• is it even feasible to make these HTTP requests as a part of the build process without making build times unacceptably slow?

I'm still working on a sloppy proof of concept, so – TBD!