A few quick optimization tricks I used to save $$ when my scrappy website multiplied.me became too popular

Drew Jarrett
4 min readSep 7, 2020

What do you do when that scrappy website you built in your personal time — for just friends and family — somehow ends up being shared and starts getting 1000s of hits a day! Here are a few quick ways I optimized it to support more load, and importantly avoid running into large serving bills.

Firstly, a quick background…

Hi, I’m Drew. A Customer Solutions Engineer at Google. I’ve worked in our Sydney and London offices. Currently I’m in beautiful Sydney tackling ads, websites, apps, and data related challenges.

Earlier in the year when the pandemic hit I became a little too obsessed with checking the COVID-19 numbers each day. Annoyingly (to me) these numbers were only reported at a country or state level, when I really wanted to see what’s happening around me and my family.

So I did what I knew best, built a website - multiplied.me (Note: I’ll probably take this down in 2021 if you are reading in the future). The site updates daily from, and helps visualize, Data NSW and GOV.UK Data datasets. Disclaimer: This was a personal project not unrelated to my work at Google, and as such it’s super scrappy. Credit: To my brother Chris for helping with the UI.

So what quick changes did I make to support the load?

Server End

Static everything

Some website elements are screaming to be made static e.g images that’ll never change, while some elements should probably be kept dynamic e.g javascript you need to update frequently. I made everything static. Yes it’ll make updates annoying, but think about how much it reduces serving cost.

“There are no instances deployed”

App Engine has the concept of idle instances (check out the page on Scaling). An always running idea instance(s) is ready to go, so users experience zero latency. I didn’t do this. Maximum latency, minimum cost. This is not good for a production website, slow is not good.

My first user calling an endpoint (yep an endpoint, the static content wouldn’t need an instance to load) will have to wait for an instance to load up first, ~1min max. Meaning, I don’t need to pay to keep instances running.

Memcache

App Engine Memcache is an in memory (Mem) cache service. In this case, allowing me to cache the results users have requested so I can avoid calling my Database (BigQuery) a second time in the same day for — and paying for — the same request. I’m caching on postcode / town, which is working great as the majority of calls are coming from similar areas (I assume due to the way it was shared by my family and friends).

Front End

Zoom in please!

Unless the user is zoomed in past a specified amount, and within specified lat/lng boundaries i.e Australia NSW and UK lat/lng boundaries where I know we have data for, the code won’t make a request to the endpoint for information on that area.

Acknowledged, this is not the best user experience — again, not recommended for a production site — but in my defense the site was made for viewing ‘around me’ not a detailed zoomed out view of everything. If only I had more time to develop it further 😅 but for now we can avoid unnecessary server calls in areas where we have zero, or too much, data.

Local cache

I’ve created a ‘loaded bounds’ object to remember what has already been loaded, as the user pans and zooms around the map to see what’s happening in other areas of interest. Avoiding unnecessary server calls requesting the same information again.

Timeout

A trick I was taught a few years back, wait a second before asking the endpoint what’s going on in that area. It’s possible the user is still looking for their area of interest and may pan/zoom again. Avoiding unnecessary server calls requesting information the user doesn’t care to see.

I hope some of these ideas have been useful, let me know. Thanks for reading.

--

--

Drew Jarrett

Working @Google across SYD & LDN. Developer. Innovative. Problem solver. Passion for making a difference through what I do. Proud Dad of two amazing girls.