{"id":296693,"date":"2019-10-16T08:06:11","date_gmt":"2019-10-16T15:06:11","guid":{"rendered":"https:\/\/css-tricks.com\/?p=296693"},"modified":"2019-10-16T08:06:11","modified_gmt":"2019-10-16T15:06:11","slug":"workflow-considerations-for-using-an-image-management-service","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/workflow-considerations-for-using-an-image-management-service\/","title":{"rendered":"Workflow Considerations for Using an Image Management Service"},"content":{"rendered":"
There are all these sites out there that want to help you with your images. They do things like optimize your images and help you serve them performantly.<\/p>\n That’s a very good thing. By any metric, images are a major slice of the resources on websites, and we’re notoriously bad at optimizing them and doing all the things we could to lower the performance hit from them. I’m sitting at a conference right now and Dave<\/a> just bet everyone in the audience $100 that he could find an unoptimized image on their site. I wasn’t about to take him up on it.<\/p>\n So you use some service to help you deliver images better. Smart. Many of them will make managing and optimizing images a lot easier. But I don’t consider them a no-brainer. There is a lot to think about, like making choices that don’t paint you into a corner. <\/p>\n <\/p>\n I don’t want to go to your site to upload my assets. I want to use the media management in my own CMS. So, the service should have an API at a minimum, and possible even officially maintained CMS plugins.<\/p>\n This site uses WordPress. I can drag and drop images into the media library and posts very easily. I can search my media library for images I’ve uploaded before. I like that, and I want to take advantage of it today, and as it evolves.<\/p>\n If it also<\/em> has to be uploaded to the image service, that’s fine. But it should go to my server first, then to the service. That way, I still maintain ownership of the source file.<\/p>\n I’d prefer that the images within content are stored as totally functional HTML in my database:<\/p>\n It could be fancier than that, like using The implementation of the image service will involve filtering<\/em> that HTML to do whatever it needs to do, like replace the URLs to generate fancier responsive image markup and whatnot.<\/p>\n Between having functional HTML and images on my server, that enables me to turn off<\/em> the image service if I need to. Services have a habit of coming and going, or changing in ways that make them more or less palatable. I don’t want to be locked-in; I want freedom. I want to be able turn off the service and have a perfectly functional site with perfectly functional images, and not be obstructed from moving to a different service — or no service at all.<\/p>\n I just mentioned filtering the HTML for images in my database. That should happen for all<\/em> the images on my site, even if they were uploaded and used before I started using the image service.<\/p>\n This probably means the services offers a URL-based “get” API to optimize images on-the-fly pulled from their canonical locations. <\/p>\n I want to upload whatever I have. Probably some huge un-optimized screenshot I just took. If I think about it at all, I want to upload something much too big and much too high-quality so that I know I have a great original version available. The service will create optimized, sized, and formatted images as needed.<\/p>\n I also want to upload SVG and have it stay SVG (that’s also optimized).<\/p>\n CDNs are vital for speed. Australians get images from servers hosted in Australia. Canadians get images from servers hosted in Canada. The servers are configured to be fast and cookie-less and all the fancy over-my-head things that make an asset CDN scream.<\/p>\n If you serve images in WebP format to browsers that support it, you’ll probably get as much or more performance out of that optimization than serving re-sized images with responsive images syntax. It’s a big deal. <\/p>\n I want the service to know what the best possible format for any particular image for any particular browser and serve the image in that format. This is going to change over time, so I want the service to stay on top of this so I don’t have to.<\/p>\n I know that involved formats like JPEG-XR and JPEG-2000 three years ago<\/a>. Is that still the case? I have no idea. This is a core value proposition for the service.<\/p>\n This is perhaps the most obvious feature and the reason you reach for an image service in the first place. Images need optimization. There are perhaps dozens of image optimization tools\/algorithms that aim to squeeze every last byte out of images. The image service probably uses those or even has its own fancy tech for it. Ideally, the default is to optimize an image the most it possibly can be without noticeably hurting the quality, but still allowing me to ratchet it down even more if I want to. <\/p>\n A lot of image services have some sort of tester tool where you drop in a URL and it tells you how bad you’re doing with images. Many of them test the size of the image on the rendered page and compare the dimensions of the original image. If the original image is larger, they tell you could have had savings by sizing it down. That’s obnoxious to me. High-pixel density displays have been around for a long time and it’s no crime to serve them.<\/p>\n Not all images benefit from the same responsive breakpoints. Check out the site Responsive Image Breakpoints<\/a>. It generates versions of the image that are best depending on the image itself<\/em>. That’s the kind of help I like to see from an image service. Take something hard and automate it for me.<\/p>\nHere’s the type of service I mean.<\/summary>\n
\n
I should be able to upload images from my own CMS.<\/h3>\n
The images should be uploaded to my own server.<\/h3>\n
Images within content should use functional, semantic markup in my CMS.<\/h3>\n
<img src=\"\/images\/flower.jpg\" alt=\"a blue flower\"><\/code><\/pre>\n
srcset<\/code> (but probably not sizes as that will change as the design changes), or be contained within
<picture><\/code> or
<figure><\/code> elements… whatever you like that makes sense as semantic HTML. The most important thing being that the content in my database has fully functional HTML with a
src<\/code> on the image that points to a real image on my real server. <\/p>\n
Even if I didn’t use the service in the past, I want all my images to benefit from it.<\/h3>\n
I shouldn’t have to think about format or size.<\/h3>\n
The images will ultimately be served on a CDN.<\/h3>\n
The images should serve in the right format.<\/h3>\n
It should optimize the images and handle quality.<\/h3>\n
Don’t shame me for using high-pixel density images.<\/h3>\n
It should help me serve the right size for the device it’s on and the perfect responsive syntax if needed.<\/h3>\n