A while back, I decided I wanted a nice visual listing of my publication’s articles from Medium to appear at the bottom of my web site. Conveniently, most of the info I needed to accomplish this existed in my publication’s feed.
For many Medium publications, the feed can be found like so:
For others, like Hackernoon, it’s more like this:
PHP-wise, it’s a pretty simple matter of just doing a file_get_contents(), and then parsing out the info for display. On my site, it winds up looking something like this, once it’s all nicely CSS-ified:
I thought all was fine with it (and it was, technically), until I happened to run some speed tests on my site (over at GTmetric.com, which runs a whole bunch of useful tests). Turns out it recommended that I compress my images.
Hmm… how could I compress those images for faster pageloads, when I have no control over them?
Then I noticed that the images are coming from Medium’s CDN, with a URL like so:
Interesting, eh? In this case, the picture being loaded is at:
… or, to show it visually:
The interesting part of that image address, though, is the “1024,” as it pretty clearly represents the width in pixels of the image (though the one shown above was auto-resized by Medium to fit here).
On a whim, I thought, “Hmm, what if I try the same URL, only I change the 1024 to some other (smaller) dimension? Could that possibly work???”
Amazingly… yes! It looks like it basically can accept any dimension (although I only tried reasonable ones … not sure what would happen if you put “1000000000” in there, or something insane — hope that wouldn’t blow up the internet!).
So, apparently there’s some mechanism in place, via Medium and/or its CDN that resizes and stores images based on that value in the address for images.
Implications / Utility
What this means for those interested in building out visual feeds like the one shown is that you can request exactly the size image needed for your situation. And that’s pretty cool because, for the picture above, the default 1024px pic is 208k. When I changed that to the exact size I needed (336px wide) that image reduced to 30k.
Ergo, for me, that meant I’m saving somewhere around 178k per pic, and I’m loading 9 on my page, for a savings in excess of 1.6Mb per pageload. Not bad!
Jim Dee heads up Array Web Development, LLC in Portland, OR. He’s the editor of “Web Designer | Web Developer” magazine and a contributor to many online publications. You can reach him at: Jim [at] ArrayWebDevelopment.com. Photo atop piece is adapted from “Tortoise shell 8” by Georgia Reading (Flickr, Creative Commons). Please 👏 👏 👏 for this article if you liked it (by clicking the applause icon below), as it helps others see it.