Tueri - Effortless Image Management

The Struggle to Price My Startup and How I Finally Launched Tueri.io

Dane Stevens — Wed, 14 Aug 2019 00:00:00 GMT

When I started the process of trying to price my startup I became overwhelmed with questions and doubts. Should we have usage-based or a tiered pricing model? How much storage can we offer at each tier? Should we offer a free plan? What should the base price be? What if no one wants to pay for this? What if Tueri is a failure?

I have spent countless hours trying to answer these questions and pricing has been the single most daunting part of launching Tueri. Tueri is a completely bootstrapped startup and ultimately, pricing can be the life or death of it. Investor money is non-existent, meaning the company needs to be profitable at every stage of growth.

It boils down to these two essential questions:

Can I provide exceptional value and service to my customers at this price?
At this price, can Tueri continue to grow and be on the leading-edge so I can continue to deliver exceptional value and service?

These two questions may seem at odds, but they are essential for building a long-term, customer-centric company.

What is Tueri?

The word Tueri is a Latin word that means: preserve. Tueri is an image management and optimization platform based on the idea of an immutable master image.

Tueri uses just-in-time image transformation, compression and conversion to deliver the perfect image to each one of your users in just milliseconds.

The idea for Tueri came during my work as an application developer. As a developer, I build customer-incentive applications for automotive parts companies. The basic premise for these sites is the more auto parts a customer (mechanic shop) buys, the more points they earn. Customers redeem points online for everything from golf clubs to TVs to vacations.

These websites receive daily file feeds from vendors with new, discontinued, and updated products. There are thousands of products and no standardization on image dimensions, file sizes or image hosting HTTP protocol. I built Tueri to solve these problems.

The first version of Tueri was a simple proxy server designed to fetch remote HTTP images and re-serve them over HTTPS, removing insecure-content warnings on our customer-incentive sites.

The next version was a simple one-page PHP script using GraphicsMagick. This script fetched a remote image, resized the image if it was over a predefined width, stored it on the server and served the image over HTTPS.

These iterations soon progressed in scope and features and somewhere along the way, I realized it was saving me obscene amounts of time.

I needed to share this with other developers.

After a lot of work converting a personal project into something I could host for others, I was ready to launch. The only problem was, I had no idea how to price it.

Should we offer a free plan?

Here are some reasons why a free plan makes sense:

User Acquisition — Offering a free plan can help you acquire a ton of new users. This, in turn, should drive growth through word of mouth marketing.
Upselling — A user on the free plan can be upsold to a paid plan.
Supporting the Community — In my jobs as a developer, I have relied on countless free services and have benefited greatly from the open-source community.

My fear of not offering a free plan was that I would have a very hard time acquiring new users. I struggled with this question what seemed like hundreds of times, so I did some research.

I researched countless other startups. I wanted to know whether they offered a free plan, what features they included, what percentage of users were on it and if they were profitable.

I discovered the following:

Free users will drive growth through word of mouth, but they will drive more free plan growth.
A free plan will help you acquire more users, but only a very small percentage of those users will ever convert to a paid plan.
A huge percentage of support is dedicated to free users.
A free plan product is often inferior due to costs associated with back-end services.
This inferior product is the product that people come to know your business by.

The Free Plan Decision

I have decided not to offer a free plan in order to dedicate 100% of our resources to our paying customers. This ensures both the quality of the product and exceptional customer service.

Should we have a usage-based or tiered pricing model?

Usage-Based Pricing

Pros:

Only pay for what you use.
Better for companies with seasonal usage fluctuations.
Better for individual developers where low monthly spend is a priority.

Cons:

Difficult to understand what your actual monthly bill will be.
Potentially drastic monthly bill fluctuations.
Harder for a developer to pitch to their company.
Customer mentality is focused on limiting usage to keep costs down, thus decreasing the perceived value of the product.

Tiered Pricing

Pros:

Easy to understand your monthly bill.
No monthly bill fluctuations.
A fixed monthly amount is an easy pitch for a developer to make to their company.
Customer mentality is focused on getting the most value out of their plan, thus increasing the perceived value of the product.

Cons:

Harder to appeal to all use cases.
Not as ideal for seasonal use customers.
Hard to appeal to individual developers with a minimal budget.

I scoured hundreds of pricing pages from different Software as a Service (Saas) companies; some simple, some complex. I continually gravitated toward tiered pricing models based on the fact that they were easier to understand. Many companies with usage-based pricing dedicate an entire page to explaining how to calculate your monthly bill. Even after following the examples I still could not say for certain what they would cost me.

Let's talk about an example of usage-based pricing for Tueri. Let's say its priced per image transformation. You have a simple responsive website with 10 pages and 10 images per page for a total of 100 images. You check Google Analytics for device usage: you have one desktop resolution, one laptop resolution, two tablet resolutions (portrait and landscape) and two mobile resolutions (portrait & landscape). If every image on every page gets viewed ten times by each resolution you have a total of 6,000 transformations.

Easy right? Not exactly.

In reality, you may have 10,000, 50,000, 100,000 or more page views a month. You could have 20+ different resolutions, HiDPI displays, pages with varying levels of views, and new images added regularly.

You can see how this gets complicated.

The Pricing Model Decision

While it was not an easy decision to make, I concluded that tiered pricing was right for Tueri due to its transparency and simplicity.

What should the base price be?

This has to be the single most difficult question to answer, at least it was for me. One that I will continue to ask and re-evaluate throughout the lifetime of Tueri.

I had to assess:

Are we a premium or a value company?
What type of users do we want to focus our service on?
Do we want to serve millions of customers at a low price or thousands of customers at a higher price?
Can we continue to provide exceptional service to our customers at this price?
What is the time value we are providing to our customers?
What is the monetary value we are providing to our customers?
What does our competition charge, are they profitable, and is their business sustainable?

It boils down to defining priorities:

I want to provide an exceptional level of service to fewer customers.
I am in this for the long-haul and our pricing needs to be sustainable.

The Base Price Decision

Pricing should not be static, you should assess it over time based on feedback from customers, the added value from new features, and operating costs.

We are constantly evaluating our pricing and I would love to know your use case and if our pricing works for you. dane.stevens@tueri.io

Conclusion

I finally realized that I was never going to have it all figured out, so I made the best decisions I could with the available information and launched.

There is no definitive answer to pricing your startup, but keep these things in mind and you won't go wrong:

Exceed your customer's expectations in the service and value you provide.
Price your business for growth.
Launch your startup.
Reevaluate your pricing continually.

Do you have any tips or questions about pricing your startup? Get in touch dane.stevens@tueri.io

How to Automatically Cross-post from Your GatsbyJS Blog with RSS

Dane Stevens — Fri, 07 Jun 2019 00:00:00 GMT

With the recent exodus from Medium many developers are now creating their own GatsbyJS Blogs and then cross-posting to Medium or publications like dev.to.

Cross-posting is time-consuming, but necessary to drive traffic to your personal site. Let's look at how we can automate this by adding an RSS feed to your personal GatsbyJS blog.

Add Canonical URL's to Your Blog

What is a canonical url?

A canonical url tells search engines which page is the primary or authorative page when duplicate content is found (ie. cross-posting).

Let's install gatsby-plugin-canonical-urls

Quick tip: npm i is an alias for npm install --save

npm i gatsby-plugin-canonical-urls

Note: If you are using gatsby-plugin-react-helmet install this plugin instead: gatsby-plugin-react-helmet-canonical-urls*

npm i gatsby-plugin-react-helmet-canonical-urls

Add plugin configuration to /gatsby-config.js

// In your gatsby-config.js
plugins: [
  {
    resolve: `gatsby-plugin-canonical-urls`,
    // or
    // resolve: `gatsby-plugin-react-helmet-canonical-urls`
    options: {
      // Change `siteUrl` to your domain 
      siteUrl: `https://tueri.io`
      
      // Query string parameters are inclued by default.
      // Set `stripQueryString: true` if you don't want `/blog` 
      // and `/blog?tag=foobar` to be indexed separately
      stripQueryString: true
    }
  }
]

With this configuration, the plugin will add a <link rel="canonical" ... /> to the head of every page e.g.

<link rel="canonical" href="https://tueri.io/2019-04-04-how-to-securely-deploy-to-kubernetes-from-bitbucket-pipelines/" />

Install an RSS Feed Generator

We'll use gatsby-plugin-feed to generate an rss feed from our blog posts.

npm i gatsby-plugin-feed

Add plugin configuration to /gatsby-config.js

// In your gatsby-config.js
plugins: [
  {
    resolve: `gatsby-plugin-feed`,
    options: {
      query: `
        {
          site {
            siteMetadata {
              title
              description
              siteUrl
              site_url: siteUrl
            }
          }
        }
      `,
      feeds: [
        {
          serialize: ({ query: { site, allMarkdownRemark } }) => {
            return allMarkdownRemark.edges.map(edge => {
              return Object.assign({}, edge.node.frontmatter, {
                description: edge.node.excerpt,
                date: edge.node.frontmatter.date,
                url: site.siteMetadata.siteUrl + edge.node.fields.slug,
                guid: site.siteMetadata.siteUrl + edge.node.fields.slug,
                custom_elements: [{ "content:encoded": edge.node.html }],
              })
            })
          },
          query: `
            {
              allMarkdownRemark(
                sort: { order: DESC, fields: [frontmatter___date] },
              ) {
                edges {
                  node {
                    excerpt
                    html
                    fields { slug }
                    frontmatter {
                      title
                      date
                    }
                  }
                }
              }
            }
          `,
          output: "/rss.xml",
          title: "Your Site's RSS Feed",
          // optional configuration to insert feed reference in pages:
          // if `string` is used, it will be used to create RegExp and then test if pathname
          // of current page satisfied this regular expression;
          // if not provided or `undefined`, all pages will have feed reference inserted
          match: "^/blog/",
        },
      ],
    }
  }
]

NOTE: This plugin will only generates the xml file(s) when run in production mode! To test your feed, run: gatsby build && gatsby serve

Here's what our feed looks like: Tueri.io's RSS Feed

For more information on configuring your feed check out the plugin docs.

Connect dev.to to Your RSS Feed

Log in to your dev.to account
Go to: Settings > Publishing from RSS or https://dev.to/settings/publishing-from-rss
Add your "RSS Feed URL" e.g. https://tueri.io/rss.xml
Check "Mark the RSS source as canonical URL by default
Click "Update"

Connect Medium to Your RSS Feed

The connection for Medium is not quite as straight-forward, but simple enough using Zapier.

Head on over to Zapier and create a free account.

"Make a Zap"

Choose "RSS" as your "Trigger App"
Select "New Item in Feed"
Paste in your "Feed URL"
Select a sample from your feed.
Choose "Medium" as your "Action App"
Select "Create Story"
Authorize your Medium account
Select your fields: make sure you select your Canonical URL
Send a test to Medium
Finish and turn on your Zap

Conclusion

Make sure Google gives you credit for your content by using Canonical URL's.

I hope you found this helpful and that it saves you lots of time cross-posting your content!

How to Securely Deploy to Kubernetes from Bitbucket Pipelines

Dane Stevens — Thu, 04 Apr 2019 00:00:00 GMT

Over 100,000 GitHub repos have leaked API or cryptographic keys - ZDNet

Hands up if this has happened to you. You're reading a well-written article on one of countless topics, and you get to the line that goes something like this:

// DO NOT DO THIS IN A PRODUCTION APP
const API_KEY = '<api-key-displayed-in-plain-text>'

Ok, so how should you be doing this? Unfortunately, there isn't a one-size-fits-all approach to securing your secrets. Different programming languages deployed in different environments all handle secrets in their own way.

Suffice it to say that you should never store secrets in your code or repository. Secrets should be passed into your app through environment variables at the last possible moment.

Bitbucket Pipelines - Continuous Delivery

I have been using Bitbucket Pipelines since it was in Alpha and I have to say, it's fantastic. It has to be the quickest and easiest way to setup continuous delivery right from your repo.

Pipelines are configured with YAML files and can be very simple or extremely complex depending on your needs.

Pipelines Configuration

I like to break up my build jobs into steps for a couple of reasons:

If a step fails, you can re-run individual steps.
Each step is isolated from the others. Only your base repo and any "artifacts" you declare will be passed to the next step.

Here is a 3-step bitbucket-pipelines.yml file that takes a create-react-app site, packages it as a Docker image and deploys it to a Kubernetes cluster:

options:
  # Enable docker for the Pipeline
  docker: true

pipelines:
  branches:
    master:
      - step:
          name: Build app for Production (create-react-app)
          image: mhart/alpine-node:10
          caches:
            - node
          script:
            # Install Dependencies
            - npm install
            # Run our Tests
            - npm run test
            # Package App for Production
            - npm run build
          artifacts:
            # Pass the "build" Directory to the Next Step
            - build/**
      - step:
          name: Build Docker Image
          script:
            # NOTE: Set $DOCKER_HUB_USERNAME and $DOCKER_HUB_PASSWORD as environment SECRETS in Bitbucket repository settings
            # Use $BITBUCKET_COMMIT to tag our docker image
            - export IMAGE_NAME=<docker-username>/<docker-image>:$BITBUCKET_COMMIT
            # Build the Docker image (this will use the Dockerfile in the root of the repo)
            - docker build -t $IMAGE_NAME .
            # Authenticate with the Docker Hub registry
            - docker login -u $DOCKER_HUB_USERNAME -p $DOCKER_HUB_PASSWORD
            # Push the new Docker image to the Docker registry
            - docker push $IMAGE_NAME
      - step:
          # trigger: manual
          name: Deploy to Kubernetes
          image: atlassian/pipelines-kubectl
          script:
            # NOTE: $KUBECONFIG is secret stored as a base64 encoded string
            # Base64 decode our kubeconfig file into a temporary kubeconfig.yml file (this will be destroyed automatically after this step runs)
            - echo $KUBECONFIG | base64 -d > kubeconfig.yml
            # Tell our Kubernetes deployment to use the new Docker image tag
            - kubectl --kubeconfig=kubeconfig.yml --namespace=<namespace> set image deployment/<deployment-name> <deployment-name>=<docker-username>/<docker-image>:$BITBUCKET_COMMIT

bitbucket-pipelines.yml

FROM mhart/alpine-node:10
WORKDIR /app
EXPOSE 5000

# Install http server
RUN yarn global add serve

# Bundle app source
COPY build /app/build

# Run serve
CMD [ "serve", "-n", "-s", "build" ]

Dockerfile

Here's the important part of all that:

- echo $KUBECONFIG | base64 -d > kubeconfig.yml

Our kubeconfig file is stored as a Base64 encoded string in a Bitbucket secret named $KUBECONFIG.

Bitbucket secrets are stored encrypted, and decrypted when you call the variable in pipelines.

We decode the $KUBECONFIG variable and store it in a temporary file called kubeconfig.yml which is automatically deleted as soon as this step completes.

Breaking it Down

Step 1

Install dependencies
Run tests
Build
Pass build directory to Step 2

Step 2

Name Docker image
Build Docker image
Push image to Docker Hub

Step 3

Decode kubeconfig
Set deployment image

Build Performance

This entire build takes less than 1 minute 40 seconds and using Alpine Node the Docker image is just 29 MB.

Conclusion

Securing your secrets isn't hard, but it starts with knowing where to look.

Some tips for securing secrets in different Node.js environments:

Node.js (Development): use .env files and .gitignore to keep .env files out of your repository.
Node.js (Production): use Kubernetes Secrets, Docker Secrets and pass as environment variables into the container.

Remember this one rule:

Don't store secrets in your code, your repository or your docker image.

Happy coding!

Your complete guide to truly responsive images

Dane Stevens — Wed, 27 Mar 2019 00:00:00 GMT

There is a lot that goes into making a website responsive, images are a major factor and can make or break your site. With that out of the way, let's dig in:

<img src="giraffe.jpg" />

Whoa! That's not quite right, let's fix that.

Percentage width images using CSS

By definition, a responsive site has no fixed width. We can account for this by setting our image width using percentages. A percentage width can be set on the image directly using inline CSS or set globally using a CSS style sheet.

<!-- Inline CSS -->
<img src="giraffe.jpg" style="max-width: 100%;" />

/* Global CSS style sheet */
img {
    max-width: 100%;
}

Our image set to 100% maximum width now looks like this. Feel free to resize your browser window and see the image width change automatically.

Awesome! Our images are now responsive, but let's not get too excited. CSS percentage widths have a major downside: This reading pane has a maximum width of 700 pixels and our image is 3742 pixels wide or 532% larger than what we need. It's also consuming 1.55 MB of bandwidth.

So the image is huge, what's the big deal?

On a standard ADSL internet connection it is going to take 2 seconds to download that single image.

I'm going to assume you have more than one image on your website. If every image takes 2 seconds to download, your site will be very slow and your search ranking will take a big hit.

How can we fix this problem?

Since we only need an image that is 700 pixels wide, let's pop open Photoshop and resize it.

That's better! Our image is now 700 pixels wide and weighs in at 264 KB with no loss of quality.

What about mobile devices?

Great question! On mobile devices, 700 pixels can be more than double what you need and 264 KB on is still slow on a mobile internet connection.

What if we could display different size images for different size devices?

Now you're thinking!

Different image sizes using the srcset attribute

Let's downsize our original image and save it as three versions of 700 pixels, 480 pixels and 360 pixels. We'll name them as follows:

giraffe-small.jpg - 360px @ 101 KB
giraffe-medium.jpg - 480px @ 151 KB
giraffe-large.jpg - 700px @ 264 KB

We'll use the srcset attribute to tell the browser about our different image sizes. This tells the browser that we have three versions of this image in the sizes 360w, 480w and 700w. The "w" in this case is the same as "px".

<img 
    style="max-width: 100%;"
    srcset="giraffe-small.jpg 360w, giraffe-medium.jpg 480w, giraffe-large.jpg 700w"
/>

Some older browsers will ignore the srcset attribute. We can use the src attribute as a fallback for these browsers.

<img 
    style="max-width: 100%;"
    srcset="giraffe-small.jpg 360w, giraffe-medium.jpg 480w, giraffe-large.jpg 700w"
    src="giraffe-large.jpg"
/>

Great! Now we are saving bandwidth by delivering different images to different devices.

This goes without saying, but you know what this means right? You'll need to create a minimum of three versions of every image on your site. If you want to support hi-dpi or retina displays, you'll need even more variations. That is an incredible amount of time that none of us have. In addition, if you re-design your site at different breakpoints, you'll need to do this all over again.

At Tueri, we're developers too and recognize that your time is valuable. In the next section I'll show you how we solved this problem for you.

Real-time image processing with Tueri.io

Tueri.io is a real-time image processing platform. We store, process, and deliver your image perfectly sized to every device.

Here's what you do

Upload your image to Tueri.io
Change the image src to tueri-src
Include tueri.js in your code

<img tueri-src="https://cdn.tueri.io/274877906982/giraffe-family.jpg"/>
<script src="tueri.js"></script>

It's like magic!

Oh, and we also do:

Low-quality image placeholders
Image lazy-loading
Image compression
Image conversion

Building the React Image Optimization Component for Tueri.io

Dane Stevens — Thu, 21 Mar 2019 00:00:00 GMT

Let’s face it, image optimization is hard. We want to make it effortless.

Full source code can be found on GitHub

When we set out to build our React Component there were a few problems we wanted to solve:

Automatically decide image width for any device based on the parent container.
Use the best possible image format the user’s browser supports.
Automatic image lazy loading.
Automatic low-quality image placeholders (LQIP).

Oh, and it had to be effortless for React Developers to use.

This is what we came up with:

<Img src={ tueriImageId } alt='Alt Text' />

Easy right? Let’s dive in.

Calculating the image size:

Create a <figure /> element, detect the width and build an image URL:

class Img extends React.Component {

    constructor(props) {
        super(props)
        this.state = {
            width: 0
        }
        this.imgRef = React.createRef()
    }

    componentDidMount() {
        const width = this.imgRef.current.clientWidth
        this.setState({
            width
        })
    }

    render() {

        // Destructure props and state
        const { src, alt, options = {}, ext = 'jpg' } = this.props
        const { width } = this.state

        // Create an empty query string
        let queryString = ''        

        // If width is specified, otherwise use auto-detected width
        options['w'] = options['w'] || width

        // Loop through option object and build queryString
        Object.keys(options).map((option, i) => {
            return queryString +=  `${i < 1 ? '?' : '&'}${option}=${options[option]}`
        })

        return(
            <figure ref={this.imgRef}>
                { 
                    // If the container width has been set, display the image else null
                    width > 0 ? (
                        <img
                            src={`https://cdn.tueri.io/${ src }/${ kebabCase(alt) }.${ ext }${ queryString }`}
                            alt={ alt }
                        />
                    ) : null 
                }
            </figure>
        )

    }
}

export default Img

This returns the following HTML:

<figure>
    <img 
        src="https://cdn.tueri.io/tueriImageId/alt-text.jpg?w=autoCalculatedWidth" 
        alt="Alt Text" 
    />
</figure>

Use the best possible image format:

Next, we needed to add support for detecting WebP images and having the Tueri service return the image in the WebP format:

class Img extends React.Component {

    constructor(props) {
        // ...
        this.window = typeof window !== 'undefined' && window
        this.isWebpSupported = this.isWebpSupported.bind(this)
    }

    // ...
    
    isWebpSupported() {
        if (!this.window.createImageBitmap) {
            return false;
        }
        return true;
    }

    render() {

        // ...

        // If a format has not been specified, detect webp support
        // Set the fm (format) option in the image URL
        if (!options['fm'] && this.isWebpSupported) {
            options['fm'] = 'webp'
        }

        // ...
        
        return (
            // ...
        )

    }
}

// ...

This returns the following HTML:

<figure>
    <img 
        src="https://cdn.tueri.io/tueriImageId/alt-text.jpg?w=autoCalculatedWidth&fm=webp" 
        alt="Alt Text" 
    />
</figure>

Automatic image lazy loading:

Now, we need to find out if the <figure /> element is in the viewport, plus we add a little buffer area so the images load just before being scrolled into view.

   class Img extends React.Component {

   constructor(props) {
       // ...
       this.state = {
           // ...
           isInViewport: false
           lqipLoaded: false
       }
       // ...
       this.handleViewport = this.handleViewport.bind(this)
   }

   componentDidMount() {
       // ...
       this.handleViewport()
       this.window.addEventListener('scroll', this.handleViewport)
   }
   
   handleViewport() {
       // Only run if the image has not already been loaded
       if (this.imgRef.current && !this.state.lqipLoaded) {
           // Get the viewport height
           const windowHeight = this.window.innerHeight
           // Get the top position of the <figure /> element
           const imageTopPosition = this.imgRef.current.getBoundingClientRect().top
           // Multiply the viewport * buffer (default buffer: 1.5)
           const buffer = typeof this.props.buffer === 'number' && this.props.buffer > 1 && this.props.buffer < 10 ? this.props.buffer : 1.5
           // If <figure /> is in viewport
           if (windowHeight * buffer > imageTopPosition) {
               this.setState({
                   isInViewport: true
               })
           }
       }
   }
   
   // ...
   
   componentWillUnmount() {
       this.window.removeEventListener('scroll', this.handleViewport)
   }

   render() {

       // Destructure props and state
       // ...
       const { isInViewport, width } = this.state
       
       // ...
       
       return (
           <figure ref={this.imgRef}>
               { 
                   // If the container width has been set, display the image else null
                   isInViewport && width > 0 ? (
                       <img 
                           onLoad={ () => { this.setState({ lqipLoaded: true }) } }
                           // ...
                       />
                   ) : null 
               }
           </figure>
       )

   }
}

export default Img

Automatic low-quality image placeholders (LQIP):

Finally, when an image is in the viewport, we want to load a 1/10 size blurred image, then fade out the placeholder image when the full-size image is loaded:

class Img extends React.Component {

    constructor(props) {
        // ...
        this.state = {
            // ...
            fullsizeLoaded: false
        }

        // ...

    }

    // ...

    render() {

        // Destructure props and state
        // ...
        const { isInViewport, width, fullsizeLoaded } = this.state

        // ...
        
        // Modify the queryString for the LQIP image: replace the width param with a value 1/10 the fullsize
        const lqipQueryString = queryString.replace(`w=${ width }`, `w=${ Math.round(width * 0.1) }`)

        // Set the default styles. The full size image should be absolutely positioned within the <figure /> element
        const styles = {
            figure: {
                position: 'relative',
                margin: 0
            },
            lqip: {
                width: '100%',
                filter: 'blur(5px)',
                opacity: 1,
                transition: 'all 0.5s ease-in'
            },
            fullsize: {
                position: 'absolute',
                top: '0px',
                left: '0px',
                transition: 'all 0.5s ease-in'
            }
        }

        // When the fullsize image is loaded, fade out the LQIP
        if (fullsizeLoaded) {
            styles.lqip.opacity = 0
        }

        return(
            <figure
                style={ styles.figure }
                // ...
            >
                {
                    isInViewport && width > 0 ? (
                        <React.Fragment>

                            {/* Load fullsize image in background */}
                            <img 
                                onLoad={ () => { this.setState({ fullsizeLoaded: true }) } }
                                style={ styles.fullsize }
                                src={`https://cdn.tueri.io/${ src }/${ kebabCase(alt) }.${ ext }${ queryString }`}
                                alt={ alt }
                            />

                            {/* Load LQIP in foreground */}
                            <img 
                                onLoad={ () => { this.setState({ lqipLoaded: true }) } }
                                style={ styles.lqip }
                                src={`https://cdn.tueri.io/${ src }/${ kebabCase(alt) }.${ ext }${ lqipQueryString }`} 
                                alt={ alt } 
                            />
                        </React.Fragment>
                    ) : null
                }            
            </figure>
        )

    }
}

// ...

Putting it all together:

Image optimization made effortless. Just swap out your regular <img /> elements for the Tueri <Img /> and never worry about optimization again.

import React from 'react'
import PropTypes from 'prop-types'
import { TueriContext } from './Provider'
import kebabCase from 'lodash.kebabcase'

class Img extends React.Component {

    constructor(props) {
        super(props)
        this.state = {
            isInViewport: false,
            width: 0,
            height: 0,
            lqipLoaded: false,
            fullsizeLoaded: false
        }

        this.imgRef = React.createRef()
        this.window = typeof window !== 'undefined' && window 
        this.handleViewport = this.handleViewport.bind(this)       
        this.isWebpSupported = this.isWebpSupported.bind(this)

    }

    componentDidMount() {

        const width = this.imgRef.current.clientWidth

        this.setState({
            width
        })
        
        this.handleViewport()

        this.window.addEventListener('scroll', this.handleViewport)

    }

    handleViewport() {
        if (this.imgRef.current && !this.state.lqipLoaded) {
            const windowHeight = this.window.innerHeight
            const imageTopPosition = this.imgRef.current.getBoundingClientRect().top
            const buffer = typeof this.props.buffer === 'number' && this.props.buffer > 1 && this.props.buffer < 10 ? this.props.buffer : 1.5
            if (windowHeight * buffer > imageTopPosition) {
                this.setState({
                    isInViewport: true
                })
            }

        }
    }

    isWebpSupported() {
        if (!this.window.createImageBitmap) {
            return false;
        }
        return true;
    }

    componentWillUnmount() {
        this.window.removeEventListener('scroll', this.handleViewport)
    }

    render() {

        // Destructure props and state
        const { src, alt, options = {}, ext = 'jpg' } = this.props
        const { isInViewport, width, fullsizeLoaded } = this.state

        // Create an empty query string
        let queryString = ''

        // If width is specified, otherwise use auto-detected width
        options['w'] = options['w'] || width

        // If a format has not been specified, detect webp support
        if (!options['fm'] && this.isWebpSupported) {
            options['fm'] = 'webp'
        }

        // Loop through option prop and build queryString
        Object.keys(options).map((option, i) => {
            return queryString +=  `${i < 1 ? '?' : '&'}${option}=${options[option]}`
        })

        // Modify the queryString for the LQIP image: replace the width param with a value 1/10 the fullsize
        const lqipQueryString = queryString.replace(`w=${ width }`, `w=${ Math.round(width * 0.1) }`)

        const styles = {
            figure: {
                position: 'relative',
                margin: 0
            },
            lqip: {
                width: '100%',
                filter: 'blur(5px)',
                opacity: 1,
                transition: 'all 0.5s ease-in'
            },
            fullsize: {
                position: 'absolute',
                top: '0px',
                left: '0px',
                transition: 'all 0.5s ease-in'
            }
        }

        // When the fullsize image is loaded, fade out the LQIP
        if (fullsizeLoaded) {
            styles.lqip.opacity = 0
        }

        const missingALt = 'ALT TEXT IS REQUIRED'

        return(
            // Return the CDN domain from the TueriProvider
            <TueriContext.Consumer>
                {({ domain }) => (
                    <figure
                        style={ styles.figure }
                        ref={this.imgRef}
                    >
                        {
                            // 
                            isInViewport && width > 0 ? (
                                <React.Fragment>

                                    {/* Load fullsize image in background */}
                                    <img 
                                        onLoad={ () => { this.setState({ fullsizeLoaded: true }) } }
                                        style={ styles.fullsize }
                                        src={`${ domain }/${ src }/${ kebabCase(alt || missingALt) }.${ ext }${ queryString }`}
                                        alt={ alt || missingALt }
                                    />

                                    {/* Load LQIP in foreground */}
                                    <img 
                                        onLoad={ () => { this.setState({ lqipLoaded: true }) } }
                                        style={ styles.lqip }
                                        src={`${ domain }/${ src }/${ kebabCase(alt || missingALt) }.${ ext }${ lqipQueryString }`} 
                                        alt={ alt || missingALt } 
                                    />
                                </React.Fragment>
                            ) : null
                        }            
                    </figure>
                )}
                
            </TueriContext.Consumer>
        )

    }
}

Img.propTypes = {
    src: PropTypes.string.isRequired,
    alt: PropTypes.string.isRequired,
    options: PropTypes.object,
    ext: PropTypes.string,
    buffer: PropTypes.number
}

export default Img

See it in action:

Try out a live demo on CodeSandbox: