The migration of findstarlink.com to Cloudflare Pages hit an issue (that I can’t describe here), but I had to roll it back for “reasons”. Would’ve been a nice cost-saver, but for now it’ll stay on S3. But the overall infrastructure of findstarlink (various components) is now quite streamlined, and pleasant to develop-for again.
I also hit an issue when trying to optimize the loading time of findstarlink.com’s homepage on slow internet connections. On such connections, it takes a long time to download and parse cities.js (600 KB uncompressed, 300 KB compressed). And the UI thread is blocked while that’s happening (often for 10+ seconds).
The obvious solution is to fetch it asynchronously, but unfortunately it isn’t straightforward:
- the website code is quite synchronous. Lots of things, like geojs.io lookups etc, rely on the
citiesvariable when they run. Everything will have to be converted to an event-driven system. - and I really don’t want a “Loading…” popup when the page starts. That feels like a cop-out for hiding poor site performance.
For issue #2 - I get that there’s probably no way around this, if I insist on loading a 600 KB file (300 KB compressed) on a slow internet connection (reproducible in Chrome Dev Tools with the ‘Slow 4G’ mode).
I don’t want to spin-up an auto-complete API just to handle the slow-internet edge case. That’ll mean very little for most of the users (who’re on better connections), and will bloat my costs.
The only reason I haven’t fully committed to the “Loading…” popup idea is because geojs.io already returns the latitude/longitude and city name. So I already have the information necessary to populate the search box and make satellite predictions. Which means that I can bypass the cities list entirely for this scenario. I still need the cities list for auto-complete, but may not need it for handling the critical feature.
I might go with this approach, since the first-load performance on slow connections is really bad right now.