Yeah, web.dev team is playing like Cloudinary is the only one, as it is THE one.
Imagine if you start to learn about responsive images and find this article — https://web.dev/serve-responsive-images/#other-options. Which image CDN (there is more than one) will you choose while having all this Cloudinary examples laid in front of you?
Rob Dodson from web.dev team told me three years ago that they won't include Uploadcare to the list:
> Happy to discuss further but in general it's difficult for us to have an exhaustive list of services so we're tending toward those that we have prior experience working with and that have a large community around them already.
Maybe this argument is fare for a small startup with very limited resources, but not for one of the biggest companies in the history of the world, that shapes our lives. I've tried to discuss it with him (https://github.com/GoogleChrome/web.dev/pull/838#issuecommen...), but you can guess there was no "happy to discuss further" part.
I'm with Uploadcare too. I think it's only fare for us (other image CDN companies) to unite agains this unfair advantage.
> Get permission before mentioning other companies, products, etc. #
> Don't mention other companies, products, services, etc. without that entity's permission. You can ask the content lead to make exceptions to this rule, which will be done on a case-by-case basis.
This guideline stays in the way of mentioning more companies. I assume web.dev authors already have Cloudinary's permission and don't bother asking anybody else. I think their content guideline requires an update regarding this rule.
I believe this article @ web.dev is an example of building an unfair advantage for the largest player in image CDN market. This seems unfair because there are many alternatives with their pros and cons, they should be listed there as well. At least if web.dev is positioned as learning center.
(full disclosure: I'm the co-founder of Uploadcare, an image CDN is a part of our platform)
by looking at the contributors list, it's most likely written by a person involved with cloudinary.
But yea, unfair. Cloudinary isn't even a CDN. Granted, it comes with a CDN on top, but it's core is image/asset management.
I need to disclose too; I'm with ImageEngine.io .
Imagine if you start to learn about responsive images and find this article — https://web.dev/serve-responsive-images/#other-options. Which image CDN (there is more than one) will you choose while having all this Cloudinary examples laid in front of you?
Rob Dodson from web.dev team told me three years ago that they won't include Uploadcare to the list:
> Happy to discuss further but in general it's difficult for us to have an exhaustive list of services so we're tending toward those that we have prior experience working with and that have a large community around them already.
Maybe this argument is fare for a small startup with very limited resources, but not for one of the biggest companies in the history of the world, that shapes our lives. I've tried to discuss it with him (https://github.com/GoogleChrome/web.dev/pull/838#issuecommen...), but you can guess there was no "happy to discuss further" part.
I'm with Uploadcare too. I think it's only fare for us (other image CDN companies) to unite agains this unfair advantage.