What Happens When an Image Request is Made

By design, the experience of using imgix is pretty seamless. Once a Source for photos has been set up, you simply put the parameters for the transformations you need into a photo’s URL and it is almost instantaneously served to your specifications.

Yet this seeming simplicity actually hides a lot that’s going on under the hood. Requests are rendered and then fulfilled by a robust content delivery network with a sophisticated caching layer. This means the request actually goes through quite a few more steps than you might expect.

There are big benefits to this sophisticated approach—it cuts latency, improves stability and maximizes performance. Yet it also has some implications for how imgix is best implemented. For that reason, we thought it might be useful to give an overview of what happens at each stage in the process.

Read the rest >

Changelog: June 30, 2017

Progressive JPEG

  • Re-enabled fm=pjpg support
  • Identified and fixed an issue where progressive JPEGs were being rendered at lower than expected quality

trim

  • Fixed an issue with the trim parameter, which was removing 1 extra row of pixels on the right and bottom edges in some cases

Dashboard

  • Added an optional field for users to record their phone number in addition to their email address, to help us with account management.
  • Fixed a bug that was causing our requirements-checker to disallow mobile browsers from logging in.
  • Fixed a broken link to our docs on the support view.

Changelog: June 16, 2017

imgix-community Slack

Effective on July 3rd, 2017, the imgix-community Slack will close.

imgix is dedicated to providing excellent support to our customers. In order to best focus our efforts and offer the best service possible, we will be dedicating our efforts to email. Support will continue to officially provide support via support@imgix.com. You can also reach out to us via our Twitter account.

Please reach out to us for all of your support needs. We’re happy to help!

imgix-java 1.10.0

  • Fixed a bug that prevented URL signing from working, by no longer naively encoding URL path components
  • Added Javadoc and source JARs to the build artifacts

Dashboard

  • Fixed a bug issue that was displaying some dollar values on the Billing view with three decimal places instead of two
  • Improved the display of null values in the “big figure” analytics numbers on the home view
  • Added a tooltip to better explain the “Cache TTL Behavior” deployment field

Documentation

  • Updated and expanded the API documentation for greater clarity, fixed a few bugs, and added a new front page to more easily get to the section you’re looking for

Changelog: June 2, 2017

imgix-rails

  • Fixed issue with widths option in image_tag() and updated to version 2.1.4

Changelog: May 26, 2017

Updated Caching Options

To make best practices for caching with imgix easier and clearer, we made a couple of changes:

  • Introduced new caching options on the Source configuration page, so you have more granular control over how imgix interacts with any Cache-Control: max-age headers present on your Master images.
  • Updated the Source setup guides (Amazon S3, Web Folder, and Web Proxy) to more clearly explain the behavior of each caching option and how best to set it.

imgix-core-js 1.0.6

  • Fixed a pair of bugs when signing URLs where the path component contained URL-encoded characters.

Dashboard

  • Fixed an issue with the URL signing tool where full URLs with query strings provided as the “path” component of the URL were getting their query strings appended to the resultant signed URL rather than encoded and signed properly.
  • Fixed a bug in the source editing & creation views where error messages were not being shown properly when submitting invalid S3 credentials.

Docs

  • Fixed font readability issues on Windows.

 Next Page