Last Wednesday, the first CodePen SF meetup happened, sponsored by imgix. There was no major headline speaker or program that was planned months in advance. The speakers and attendees were anyone interested in learning more about front-end development or design, some with no technical background. The program consisted of any brave person willing to share out a Pen they found or created themselves. You can check out our recap email and pictures from the event.
There were mistakes. There were laughs. It was genuine and human. And I’m so glad we did it.
It’s easy to find meetups where the perfect product or advice is provided, but it’s harder to find one that allows anyone—expert or not–to share something, tell a story, fumble a bit, and receive a round of applause at the end.
You see, I don’t know how to code. I only have a basic understanding of a few languages from online tutorials and playing around on CodePen. So when I went to the CSS Dev Conf back in October of this year, I truly felt like a fish out of water. I was the imposter syndrome incarnate.
At the end of the conference though, a CodePen Show & Tell was put on by Chris Coyier himself (the co-founder of the site) and for the first time, I felt like I should be there. The environment was welcoming and nonjudgmental and bits of code here and there started to make sense after seeing it being manipulated live. There was a glimmer of understanding on my part and I wanted others who aren’t developers to have it too and the idea for starting CodePen SF was born.
If this sounds like you in some way, I hope you’ll join us at our next event in February. imgix is proud to have sponsored this first event, and we’ll see you there too.
CodePen SF is back and everyone is invited.
I’ve run into a lot of varied challenges while building websites and apps over the last two decades. Every project I’ve tackled has presented unique problems, but one consistent issue has been figuring out the best way to deal with images. Every part of the image workflow is difficult; Image files are bulky, and there are lots of formats to deal with. This results in a lot of time spent processing images, and a lot of storage space required for derivatives.
imgix’s dynamic image workflow abstracts those complexities. A traditional image flow might look something like this:
- A user uploads an image. For this example, let’s say it’s a profile photo.
- A server running ImageMagick or a similar program creates derivative versions of the uploaded image. For something like a profile photo that’s used in many contexts throughout a site or app, the number of derivatives for each upload can be quite high. I’ve seen derivative counts in the dozens before!
- The original image and generated derivatives are uploaded from the image server to a permanent storage location, e.g. Amazon S3.
With imgix, the process is inverted. Instead of generating all derivatives up front, they’re requested and generated on the fly. Each derivative can be created easily by changing the appended parameters in the image URL. This allows developers a lot of additional flexibility, letting them solve some long-standing problems in new ways.
When it comes to e-commerce, study after study has shown that compelling imagery gets more clicks, leads to longer engagement and drives more sales. Pictures sell. It’s no longer up for debate.
But despite the importance the e-commerce industry puts on showcasing products with beautiful images, significantly less thought is given to how those images affect web performance. In the rush to optimize how their websites look, many e-commerce professionals ignore small tweaks that could make a big difference to how they load.
This, we think, is a mistake. The simple fact is that page load speed has a huge influence on a host of other behaviors, and image performance is one of the biggest contributors to perceived load speeds. By avoiding a few common errors, e-commerce professionals can get the most out of their imagery.
Here are the most common image mistakes we see the e-commerce industry making.
One area where we get a lot of questions is around purging images. Although purging is a familiar concept to anyone who has previously worked with Content Delivery Networks, or indeed any distributed system that needs to sync data between nodes, the concept is not the most intuitive, and every purge system functions differently. New users sometimes have an incomplete understanding of the purge process, and that can lead to confusion when the system performs differently than expected. For that reason, we thought some clarity around how image purges work in imgix would prove helpful.