Global Edge Cache
March 31, 2020 ()
From the beginning, Microlink API shipped with a built-in cache layer for speeding up consecutive API calls, aiming to improve response times for the same resource.
How cache works
When you query against Microlink API, the first time you query for a resource that wasn't previously served it will be created, what is known as a cache MISS.
The successive requests for the resource will consume the cached version, what is known as a cache HIT.
We revisited the cache layer and implemented some improvements, making it more powerful than ever.
Cache saves your API quota
npx @microlink/cli https://example.com&screenshot&embed=screenshot.url
Starting from today, any response served from the cache won't count towards your API quota.
This drastically changes how users consume the API. Let me clarify with an example.
One of the Microlink API use cases is to embed it directly in your HTML markup:
<meta name="og:image" content="https://api.microlink.io?url=https://example.com&screenshot&embed=screenshot.url" />
In the past, if you did this and your website had 1000 pageviews, it meant you consumed 1000 requests from your API quota.
Now, you only consume *one request*, serving the rest from the cache and not counting them in your API quota plan.
Cache is served around the world
The first time you hit Microlink API, the response will come from one of the servers located somewhere.
Once cached, the successive requests to the same resource will be served using the
CloudFlare Network, meaning the cached response will come from the nearest edge server in the world (and they're a lot, more than 240 edge servers in over 90 countries).
You can see how cached resources always have the lowest response time associated, no matter where you are.
Cache optimizes screenshots on the fly
Microlink screenshot is one of the most used product features these days: we’re serving around 100K fresh screenshots every day, generated in an average of ~1.5 seconds.
When you take a screenshot the image generated is hosted by us, additionally taking some special cache considerations into account.
First, the image will apply lossless compression on the fly. The image will be the same as the original but the size will be smaller, saving some bytes there.
Second, WebP will be served if the browser supports it. Most modern browsers support WebP and it can
decrease up to 42% in average image size.
Join the community
All of these improvements or features are community driven: We listen to your feedback and act accordingly.
Whether you are are building a product and you need fancy previews, you’re an indie hacker or simply you like frontend stuff, come chat with us 🙂.