The density and type of ads masks well presented information. I don't see the ads but am left unwilling to share links to the site where I sure would otherwise.
Then we recently switched ad provider, and the site grew a bit as covid started easing up, revenue doubled with the potential for more, and boom it's worth it to invest in it again.
I don't like the ads. I'd rather offer the site without them. But without them the site wouldn't be up - I'd have to turn off the servers, and there wouldn't be a map of temperature fingerprints at all.
I really wish there were a better solution. But so far there just isn't.
At least we don't do anti-ad-block ;)
(I'm one of the site creators)
In order to render in a timely fashion the sections & graphs are rendered in parallel on a decent sized instance.
That said, it might make sense to cache to protect against load spikes on specific pages, but unfortunately those don't happen a whole lot.
love the site despite the ads. who/what did you use for i18n?
Conceivably you could put up Cloudflare pages & put the assets behind a CDN with whatever TTL makes sense for how long the assets are expected to not expire for. I don't know how much that might save but certainly a cheap experiment to run.
If you wanted to experiment with a completely alternate architecture, generating them on-demand for each page's needs might be free/significantly cheaper on Cloudflare Workers. That might be a larger rewrite of the stack though and maybe worst case there are SVGs that take longer than 30s to fetch the underlying data + generate the graph.
That being said, I couldn't really tell which specific SVGs actually even needed to be generated realtime. It seemed like most of the assets would be largely ahead-of-time generated SVG w/ some localization that happens in the frontend but maybe the axis for the graphs/text within them are part of the SVG which could be something that's optimized by moving that out to HTML/JS land in the browser so that the underlying assets can have an improved cache efficiency. Certainly nothing on the front page seemed like it needed that since the map itself isn't localized & all of the heatmap summaries seem like they would be statically generated.
Not trying to push our products, just got nerd sniped by the problem.
[1] https://devclass.com/2021/04/14/cloudflare-goes-live-with-wo...
It also allows us to serve the entire page in a single request, and the gzipping of the SVGs works really well (~7x).
Keep in mind that every single graph would need 15 languages * typically 2 units = 15-30 versions. And each page has 10-20 graphs. And you can view each location by year/season/month/day, and the stations have histories sometimes going back to the 40s with a page for every single day (not indexed by Google). Not to mention the comparisons - we have some 150k locations that can be compared up to 5 at a time.
The combinatorial explosion makes pre-gen unattractive, and producing each graph in a separate request would also increase both server load and developer headaches.
If we re-architected the site today I'd probably do client side rendering of the charts, but the dev cost of making that change now would so far exceed any gains that it's not even funny.
(To be clear, the by far biggest cost of the service is developer time, not hosting cost, sorry if I implied otherwise)
is there somewhere i can read more? did you know it would cost this much before you started? was 15 languages just for completeness i can’t imagine ads paying that well in some markets
Yeah, it's a weird decision.
Google has indexed >40M pages on the site, so we'd need a little exception on that 20k limit ;)