Let’s talk first about widgets, here’s how they work, simplified:

It’s one of the quickest ways to have a webring. It’s also customizable that is in favor by the webring owner, and it’s easy to tell if the person is in the webring or not.

There are a lot of downsides though. Because it’s JS, it’s one of the things that is prone to render blocking , which basically means it blocks rendering of the website to load the JS on it. And the worst part of it is that it’s commonly a third party script, which also multiplies the page load times, as the browser also need to fetch the data from that other site.

It’s also prone on clashing with other webring widgets (commonly seen on Onionring-based webring widgets), and if the owner didn’t set it up right, it might also ruin your site layout. If the webring owner also put some assets on the widget, the browser also needs to get those to continue, and bad internet would definitely break the experience.

Webring redirects

This is the other popular one, webring redirects. Here’s how they work:

Webring redirects fixes almost all the issues of webring widgets. It offloads the processing off your site’s client-side JavaScript to the webring owner’s site or server. They are usually handled by a backend server which allows webring redirects to not render HTML at all.

Here’s how a server-side webring redirect works:

There’s also now a new kid in the block, client-JS based webring redirects. It’s less heavy than webring widgets, but you will still load an HTML page, for example, Petrapixel’s Code Collective webring which uses Webringu .

Here’s how it works:

Now, let’s go back on the thing earlier.

What is the culprit? A webring that gone dark.

This shows how third-party dependencies, not just webrings can ruin your site’s performance.

Update

I’m just checking my site’s analytics (because I am an absolute data freak), and seems like webrings strikes again!

Do I really need to do a sequel of this post so I can lighthouse some webring pages? I don’t wanna do that lmao