DEV Community: Justin

The tyranny of google page speed insights

Justin — Tue, 02 Sep 2025 00:54:22 +0000

"All good but why is the page speed insights score so low?"

The phrase that web developers just hate to hear.

The last week I have spent trying to find a balance between having a SPA (Single Page Application) that loads once and then can be used, with one that is also SEO and crawler friendly, has deep links, and also has good page speed insight scores.

Over a very short period I have had a fast re-introduction to the whole battleground of SEO vs Speed vs Functionality (it sounds like a pick two scenario).

History lesson

In the good old days of web development, php and modperl or static files we would shoot the web page from the server to the browser. Life was full of tables, and good. Sort of.

Then along came web development frameworks like React and about three dozen competitors. Suddenly it was all about hydration and shadow Dom and re-usable components. Recognisable html barely arrived at the browser any more. Instead whole chunks of JS arrived along with the "Flashes of Unstyled Content" (FOUC), and many other headaches.

But it also became about web crawlers failing to crawl your extremely js-heavy content. And it became about poor page speed ("lighthouse") scores too.

For a while google promoted a solution: renderbot! this product (basically chrome in a box) would sit on your server and render the complex pages, then deliver the final-final-really-final html to the dumb crawlers. This sounded good in practice if it could be just plugged in, but the devil was in the details. Now renderbot is render-not: deprecated by google and closed to new GitHub issues.

Solutions

A tempting solution is to just give up and build a static tree of URLs (html files) that can be crawled by all the spiders. Unsatisfying but still a solution many sites use because what else can they really do when crawlers are overloaded by the heavy task of piecing together a web page that displays a few H1 and H3 tags and a paragraph of keywords and about a million javascript instructions to get there?

Enter: server side rendering. Everything old is new again. Web-dev is back to building html complete web pages on the server and shipping them to the client where the glamorous parts start operating with sprinkles of late booted javascript.

But if you're NOT already invested in your main event being React, or Svelte5, or Vue, or NextJS or new sexy platform, then some kind of "enable SSR" (not that this is ever as easy as it sounds, anyway) switch is just not an option. What to do?

What I did

In the case of satellitemap.space the issue I faced is a satellite information website and tool needs an array of search engine friendly URLs that lead directly to satellites! and constellations! it is, after all, how many people might start with trying to get information. "where is the ISS?" "Where did that starlink satellite re-enter?"

I did have deep-links to satellites. But there was a problem. Page speed insights refused to believe the site was interactive until all the network traffic settled down. So it would give good usable URLs that opened the SPA in a certain mode, a failing grade. A deep link to the ISS would be interactive on my phone in a few seconds but google would score the URL as being a failure.

Worse, SEO-rich info related to a SPA deep-link should be mostly concentrated in the "HEAD" section of the page: the page TITLE, the meta tags, and so on. These parts appear first in the index.html that delivers the SPA, and while they can be re-written later, when the deep-link is inspected, dumb crawlers might fail to wait for that.

Enter Astro. Astro allowed me to build a page from any URL pattern, server-side, include complex js driven divs, but have a 90+ lighthouse score. I can still use tailwindcss. I can still can use any js modules or functions that the home page SPA already uses. So it was familiar. It did not require a re-think or much duplication of effort.

As a result of astro I can now add an entire satellite catalog over URLs like: https://satellitemap.space/sat/:norad_id with SEO rich headers and content, but it also loads blindingly fast from the perspective of google lighthouse:

Apart from being able to do API requests before emitting even a header line back to the browser, Astro also enables the trick of only hydrating the sections of page when they are visible, or first interacted with. In the case of the above-mentioned single satellite catalog page these were:

The Search function
The full monty webgl globe visuals plugin
The satellite description accordions
The Sky transit table
(and any others I want to add)

So now the complete pageload before any attempt to use search or scroll down to the globe plugin looks like:

that's it. vs any other typical modern website page, this is a lean. A web page with ozempic face.

Scrolling down the page causes the entire globe visualisation to boot up. (And that process was already a lot leaner than the Caesium globe library). So visually it only takes a second or two.

Pressing the Search icon causes the incremental search process to boot up.

None of these late hydrations are relevant to the page crawlers.

Another solution like Astro is Qwik - Qwik City. which is probably slightly faster still. But perfect is the enemy of good. The goal is not to go from 95 to 100 web page speed scores, It was just to not get failing web page speed scores.

Anyway. Astro rocks, I will use it next for constellation information leaf pages, and more.

Webgl shaders and POV Satellites

Justin — Sun, 24 Aug 2025 10:22:58 +0000

Today I spent time refining the POV view of the globe from a satellite. To be specific, the ISS. The basic view started like this:

Very boring. The globe at night! One can barely even discern the horizon. It is where the stars stop. That's it.

Adding an atmosphere shader got me a layer of gas. The atmosphere shader is a ray march with a simple rayleigh phase function:

As I mentioned in the last update, I'm still not happy with the atmosphere layer, but it at least reacts to the presence of sunlight, lighting up before dawn.

Switching on the "4k" globe texture instead of the dim "no distractions" texture, things are starting to look better:

But there is no cloud layer and the specular highlights on the ocean are unsatisfying. I had ocean specular highlighting on the globe when viewed from a distance so this confused me, where had it gone? tricks used at one distance rarely work well when the camera is close. So after playing around, I managed to recover the specular highlight:

So now we are starting to see something better. The sun bounces off the ocean. I can dial it up until it really glares. Sunrises and sunsets start to look better.

(Side note: webgl2 should actually support HDR. I've seen one (exactly one) good HDR particle demo that runs on chrome. HDR looks amazing when it works. Since HDR seems half baked in browsers, I put it into the too-hard basket for now. Even caniuse does not know what you mean when you say "caniuse HDR webgl". Despite being an idea since 2021, adoption is glacial. A recent discussion is here: https://discourse.threejs.org/t/true-hdr-color-support/78370 )

Turning on the cloud layer now. Most critically, making sure cloud shadows are working wrt. the sun gave more of a 3d effect. This the final result:

Sometimes it looks pretty good in motion with the bright sun glare effects off snow and some lighter coastal waters and cloud drop shadows.

To get anything close to correct physical rendering is a deep rabbit hole especially when it also has to work at different camera distances. I should stop.

A real ISS picture of the horizon is so much better. Looking at reality vs the sim again perhaps the specular glint color should be more gold and less blue? Ok maybe I can play with it a bit more...

Feature update.. POV mode

Justin — Sat, 23 Aug 2025 03:09:23 +0000

If you own an Apple TV you'd know they like to show screen savers of drone shots and what looks like a 4k video from the ISS showing the globe and horizon so today I added POV mode for any satellite.

This as usual proved to be more challenging than expected. Just stick the camera on the satellite, right? how hard could that be.

Firstly, the camera has to face in some direction. At first I figured facing it in the direction of travel would be sensible but this turned out to be confusing for geo-synchronous satellites whose direction of travel in earth fixed frame is not really travel at all. So for "slow" satellites, the better default camera was looking towards earth.

After implementing a pan/tilt of the pretend camera, I then struck 3d math issues. What is "up" in space even anyway? On a LEO satellite, up can be the vector from origin of earth to satellite, this is roughly orthogonal to direction of motion but on geo satellites that causes a maths collapse as "up" being too close to same as "where I am looking" doesn't work too well.

Another problem was that the spherical earth is not tessellated well for a lovely horizon view, it looked like a geodesic dome! so this required switching to high tessellation when switching into POV mode.

The next challenge was accelerated time travel reveals the approximations between satellite fixes made the camera jump at every new exact fix. So I had to re-calculate (just for the POV satellite) on every frame, the full SGP4.

As it stands the new feature is getting there. Pan/tilt works. No zoom yet. The earth looks good below in "4k" globe mode. No atmosphere. The sun and moon are impossibly small. That needs to be fixed. In fact the whole sun/moon thing (apparent size in all modes) needs re-doing, really. No mobile touch controls for the pretend webcam, yet.

The sim also showed the moon almost on top of the sun for my location (and is almost completely un-lit) and I thought that was a bug but it turns out from here at least, the moon is, in fact, almost eclipsing the sun. A few degrees away in altitude and azimuth.

You can get into POV mode from the last Actions button of a satellite info panel:

Well, happy with this new mode. A lot of things still to touch up however. No good feature goes unpunished!

Feature update

Justin — Wed, 20 Aug 2025 03:08:45 +0000

A few things have been added in the last couple of days I should probably explain them here as a way to get used to dev.to posting.

Selection of satellites

With 8000 something starlink satellites in the visualiser (or many more if all satellites are loaded) it became quite frustrating to select and unselect individual ones by point and click or touch. To make this easer there is now a widget that keeps the recent selections in a stack. This widget allows

clicking the item to zoom the camera to it
clicking the information symbol to open the larger panel of detail that USED to open
clicking the x to un-select that satellite
clicking to unselect all of them. Oh also you can move that little widget around using the grab handle in the left corner:

Copy/pasting TLEs

I get good suggestions via Feedback but if you don't leave your email I can't say it's implemented. From the satellite information panel you can now click the button to copy the TLE into your clipboard

Faster on slow connections

Using the network test tab of chrome with "simulate slow connection" it became clear that some textures were making the boot-up pretty unbearable in that scenario (for example, mobile + 3g). Worse, the largest textures are optional: for example, the background universe texture, or the detailed country borders. Now these textures are not loaded if the connection is detected to be slow. The time to load with no constellation selected is dramatically faster and even though loading "all of starlink" involves quite a bit of data, it is now bearable. Since this website is a SPA (single page app), the loading is one time. There is more work I need to do in this area.

Deep linking

I'm trying to build out the deep linking in order to go straight to a feature. For example:

https://satellitemap.space/constellation/kuiper
https://satellitemap.space/altitude-history?norad=25544 There might still be bugs with deep links and/or the browser back button.

Some random new-ish features:

Altitude history

After loading a constellation, you can go to Functions .. Timeline and this shows some tabs including growth (the default), launches and so on. In the Launches tab, the groups of satellites are now clickable :

and this goes straight to the altitude-history URL which ...

... plots their mean altitude all on a little graph.

Constellation altitude slots

Another interesting tab displays how the satellites in a constellation are grouped by altitude, with this year being compared to previous years.

You can see the bump at 360km for the 'direct to caller' starlink hardware in 2025 that was not there a year ago.

Re-entry view

This is an old feature but had bugs, now it doesn't have bugs. This screenshot shows the "exploded" view of the starlink constellation (the button with the blue box with exploding sides has been pressed) plus the "Re-entry risk" filter with everything de-selected except <180km. If you look carefully to the middle right of the globe you can see two red starlink satellites that are about to meet a fiery end.

satellitemap.space

Justin — Wed, 20 Aug 2025 02:41:55 +0000

I decided to start this dev.to account to document changes made to https://satellitemap.space over time. I'll find a good place to link to it from the site itself.

The audience is me for a dev diary. Plus, anyone that uses the site and is for some strange reason interested in a more detailed description of ongoing progress & features (with maybe some nuts and bolts dev chat). So this is it. The first post.