mpulp: Recent Episodes
None
Similar to the better known robots.txt file, the carbon.txt file is also a txt file located on your webserver.
This text file is meant to keep information about the resources used to serve your website and information related to your own carbon footprint.
In other words, it is a convention for website owners and digital service providers to demonstrate that their digital infrastructure runs on green electricity.
The Green Web FoundationThis is an initiative spear-headed by The Green Web Foundation, and to be fair, the initiative is still in its very early stages. However, I think the idea is so great that I think everyone should implement it!
Even if the pilot is currently only for service providers, the general idea makes sense for any website owner.
If you already have a Sustainability Policy, and maybe you’re even offsetting carbon too, the carbon.txt is a great place to be public about it!
carbon.txtis a canonical location where your carbon footprint is documented. Easy to find.carbon.txtis readable by humans, and crawlable by machines!
Make your own carbon.txtI’ve been implementing carbon.txt for ImageEngine as a part of the pilot.
An example for sites using ImageEngine as a CDN, and Netlify as hosting:
[upstream]providers = [ { domain = "netlify.com", service = "shared-hosting" }, { domain = "imageengine.io", service = "cdn" }][org]credentials = [ # Optional, but if you have a sustainability policy, you can reference it here. { domain = "yoursite.com", doctype = "webpage", url = "https://yoursite.com/sustainability/"}]
(The contents is represented using TOML syntax.)
Because imageengine.io is registered with The Green Web Foundation as a Green Host (a public data set), this will also count positively against anyone following the trances provided by the file.
Moreover, if you, or a data program, want to dig further, ImageEngine’s carbon.txt file is located here: https://imgeng.in/carbon.txt.
Ideally, carbon.txt will provide a chain of references – a “graph” if you will – where the entire footprint of the involved providers are documented.
Read more about the initiative here.
The post carbon.txt – What is it and why should you care? appeared first on mpulp.
Just like predicted, we’re back to square 1 with UA-CH vs. User-Agent.
Unfortunately, I can’t document the following claim, but I’m pretty sure that this is the case:
The reason for minority browser being locked out and/or getting a degraded experience, is client side (JavaScript) user-agent (or now UA-CH)- sniffing, performed by junior webdevs.
Vivaldi’s experience is proof enough that UA-CH sniffing is bad practice. The UA-CH initiative only made the problem worse by giving more powerful tools and lowering the efforts to make use of them (the UA-CH js api totally ungated! )
Now, situation is worse than before UA-CH. With only the user-agent we had only one lie which could be well managed by proper device detection. Now we have two lies which may tell separate stories.
The post Enter UA-CH lies appeared first on mpulp.
To make your app, website, product or service carbon neutral is easier (and cheaper) than you might think!
Frankly, it’s so easy and cheap that everyone should be doing it. It feels good!
Here’s how to go Carbon Neutral.
- Find out how much electricity is neededAs difficult as it sounds, you can use common “proxy metrics” which will give a reasonable estimate.
One such “proxy metric” you can use to derive how much electricity you need to offer your service is the amount of traffic your app or site has. Traffic in terms of (giga-) bytes.
The gigabytes (GB) your app or site generates may be an estimate itself. Unless you’ve got access to logs and monitor this carefully, you may use tools like webpagetest.org, lighthouse or similar to get an idea of how many bytes one page view generates.
From here things get a little easier thanks to other people’s efforts. There are mainly two models you can follow: the 1 byte model, “by spend” and the Sustainable Web Design model (SWD).
I’d recommend the SWD model because it’s very broad, top-down, flexible, transparent and it’s relatively compliant with other standards in the space, such as the GHG protocol for reporting scopes.
Example to estimate electricity spendThe formula used by SWD is:
Electricity = [Data Transfer per Visit (new visitors) in GB x 0.81 kWh/GB x 0.75] + [Data Transfer per Visit (returning visitors) in GB x 0.81 kWh/GB x 0.25 x 0.02]
Let’s say loading a representative page on your website weighs 3 MB everything included. Your website has 1000 visits per month. 70% are new users, 30% are returning users (they have some html, css, js images etc. in their browser cache so they’re downloading only 2%).
Then the formula would be:
(0.003 GB x 0.81 kWh/GB x 0.7) + (0.003 GB x 0.81 kWh/GB x 0.3 x 0.02) = 0.00171558 kWh/visit.
(The 0.81 kWh/GB and 0.02 are defaults from the SWD model and can be changed if you have better data)
To arrive at a yearly estimate for electricity needs in our example, the formula is then:
1000 visits x 0.00171558 kWh x 12 months = 20.59 kWh.
2. Find out how much CO2 the electricity generateTo figure out how much CO2 emissions the 0.00057186 kWh cause, you can use services like Electricity Mapsto find the carbon intensity of electricity. This varies drastically around the globe.
In Norway, the carbon intensity of 1 kWh is 25 grams CO2e, while in India and many US states it’s well above 700 grams CO2e.
The SWD model uses a global average of 442 grams CO2e/kWh.
This number can be adjusted to where your data center is geographically located, whether it’s powered by renewable energy, and where your users are located.
Using the default, 442 g/kWh, our example looks like this:
20.59 kWh x 442 g/kWh = 9099 g CO2e = 9.1 kg CO2e.
Our website has a yearly carbon footprint of 9.1 kg CO2e.
(Which is about the same as driving a modern fossil car 74.40 km)
- Buy carbon offsetsIn order to claim carbon neutrality, our example site must make up for the 3 kg CO2e.
This is done by “offsetting”. You need to buy “carbon offsets” to compensate for your emissions.
This business is, to be honest, a little prone for scams. To avoid this article being too long, I’ll just say; do research, make calls, send emails, look for companies offering projects verified by Gold Standard, Verified Carbon Standard and Climate Action Reserve. Look at google for potential places to buy.
From good vendors with good projects offsetting 1 metric tonne (MT) of CO2e costs in the range of $16 – $30.
Back to our example. What’s the cost of compensating for the emissions of our website?
0.003 tonne CO2e x $30 = $0.27 per year
…honestly, everyone can afford $0.27 per year for a site with 12000 visits per year.
ConclusionYes, the calculation is not accurate and not perfect. It’s a qualified guess based on the data we have available.
However, we have to start somewhere. The SWD model, the 1 byte model, or even a “by spend” models (emission by money spent running your app or site) are all great places to start figuring out the carbon footprint. The rest is so easy and so cheap that everyone should do it!
The post 3 Steps to Make Your App or Site Carbon Neutral appeared first on mpulp.
The Chrome Lite Mode, also known as “Data Saver”, introduced in 2014 to help users save data and speed up page loading, was removed in version 100 of Chrome.
With ImageEngine, we’ve seen a drop from around 20% of all requests having the Lite Mode enabled to between 2 and 5 %.
99% of those with Lite Mode enabled today are Smartphones. Lite Mode is still available for Androids.
To make the browser send the save-data:on header, Android users must enabled it in the system settings. This feature came in M102.
Question is why people enable Lite Mode. Google disabled it because “data cost has lowered”, but of course Google wanted to save money by not maintaining the servers that did transcoding.
Do users enable Lite Mode really want to make the page load faster? If cost is no issue, then there must be other reasons (or Google is wrong).
The post Chrome Lite Mode appeared first on mpulp.
This is a moving target! I’ve been covering the topic before both in Client Hints in general and for User-Agent Client Hints. The architecture is pretty complicated when you first experience it, but it makes sense: First, the website must opt in to the hints it needs, then the browser sends them to the server […]
The post How to Opt-In and Delegate Client-Hints appeared first on mpulp.
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 […]
The post User-Agent Client-Hints, take 2 appeared first on mpulp.
The Next-Gen Image format AVIF is the latest arrival in the image optimisation space. What is AVIF? And how does it how much better is it?
The post Meet AV1 Image File Format, AVIF for short appeared first on mpulp.
I’ve always been working with remote teams. For this reason probably, I like to try new ways to collaborate. Skype was a hit for a long time. Yammer too. But then came Slack. First release of the Slack app was done in 2013. A year later, it had already been on the radar for a […]
The post Where would we be without Slack? appeared first on mpulp.
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 […]
The post User-Agent Client-Hints Security Concerns appeared first on mpulp.
‼️ Note: there is an updated version of this article here. User-Agent Client Hints (UA-CH) has been hot in the Chrome camp lately. Motivated by the sudden urge to deprecate the User-Agent request header due to privacy concerns. With Chrome version 84 and higher, the plumbing with delegation through feature- or permission policies is implemented. Delegating UA-CH to a […]
The post Delegate User-Agent Client-Hints to 3rd Parties appeared first on mpulp.
Updated May 2021 to talk about permissions policies in stead of feature policies. Many moving parts related to Client Hints were enabled by default in Chrome version 84. Starting in this version, access to Client Hints can be delegated to 3rd parties. 🎉 Client Hints Client Hints has been here for a while – since Chrome 35 in […]
The post Client Hints and Permissions Policy appeared first on mpulp.
This morning I was reading an important reminder from Jeremy Keith. It’s about Progressive Enhancement works and how the server plays an important role in the enhancement step of the process. Even with better tools and abilities for client side work, we still need a server to produce some content and send it to the browser: These […]
The post UA-Client-Hints and Progressive Enhancement appeared first on mpulp.
I’ve been following the development of this initiative from Google more or less since it was first filed as a note on Github. Yesterday, the Chrome team announced an “Intent to Deprecate and Freeze: The User-Agent string”. Along with this intent, an intent to ship Client Hints infrastructure and UA Client Hints is published. “UA […]
The post Client Hints replacing the User-Agent appeared first on mpulp.
ImageEngine: Device Detection by WURFL, helps ImageEngine outperform alternative solutions by 42%!
The post ImageEngine Secret Sauce appeared first on mpulp.
I was really exited when I learned that Safari decided to support video content in image tags! It was scheduled for iOS 11.3 which was supposed to ship Safari 11.1 with all sorts of goodies. I’m not covering service workers here. I’m more exited about replacing animated gifs with mp4 video in <img> tags!
Converting gifs to mp4 is generally a great idea because mp4 is so much more efficient from a web performance perspective than gifs. My hope was that we finally could seamlessly serve optimized content without using any client side javascript hacks but leave the decision to the server, or leverage services like ImageEngine.
iOS 11.3 with Safari 11.1 was supposed to give us opportunity to replace our gifs with video:
<img src="video.mp4" alt="animation" />
On desktop Safari this works as expected. If you’r reading this page with a Safari 11.1 or above, you’ll see an animation below:
…but if you’re in a iOS device with iOS version 11.3 you’ll see a broken image….
Looking at the User-Agents, there is some unexpected differences:
User-Agent macOS:
``` Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15
```
User-Agent iOS:
``` Mozilla/5.0 (iPad; CPU OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1
```
Seems iOS Safari is stuck at version 11.0 and behind in the build numbers. All other announced functionality, like service workers, is available. But not video content in image tags…
According to the Safari TP release notes, the browser will announce its support for video media in image contexts by adding video/* to the Accept header if this is supported. iOS Safari does this, but still no video…
So apparently, the earlier announced Safari 11.1 shipment with iOS 11.3 did not happen. The User-Agent says version 11.0 and this is probably correct since it’s not until version 11.1 video content in image contexts is available. On the other hand 11.1 is also the version supporting service workers, but this is also supported by version 11.0 on iOS even if service workers are not mentioned in the 11.0 release notes.
So, something is off here. I submitted a bug.
So, Safari 11.1 didn’t make it to #iOS 11.3?
— Jon Arne S. (@jonarnes) April 4, 2018
The post Video in Image Tags appeared first on mpulp.