Mostly just for identified issues I still have to fix…
That resolves the issues I’m aware of. Please report any others you notice.
Thumbnails now smaller and radically reduced in size! Images now given full path in the feed.xml file which should resolve email images.
I’m not sure I actually need to sync up the images directory with everything being served out of the generated images… will take a look at that.
I can’t seem to reply to your most recent blog. It takes me to the forum but there is no reply button.
I thought I fixed that this morning.
Can you access this topic directly and reply? The Blog is Back
I changed permissions on the Comment forum around 7AM Mountain.
Just tried with a new test account and it appears to be working properly - I wonder if there are some lagging permissions issues I need to hunt down.
Ah now it is working - probably mere moments before I posted. Thank you!
Great!
A few more bits and pieces to work through still, but it’s shaping up into something sane, at least.
Alright. Links fixed, email signup should be working again, and, turns out, I do need the images directory.
@Syonyk a couple of redirects are giving me 404s, but mostly things look good.
First two Google results for “syonyk blog”
The link on Pine blog
They might be the same issue. All three appear to link to not specific articles: 2020 posts, August 2020 posts, feeds/posts/default.
As any of these were sufficient to find the blog, might just be good enough.
Yeah, there are some redirect concepts (to “all posts in 2020” or such) that don’t apply. I can probably create those pages and redirects manually. I just don’t have month-based listings right now, and don’t see a huge benefit to them. That’s just what Blogger did. I’ll poke with those some this weekend.
A more useful 404 page would probably help too.
It does appear that Google didn’t follow the Blogger redirects, though. None of my search results exist anymore, which… eh, it’s fine, I don’t care about monetization anymore.
Google usually heals itself after a time.
You can use webmaster tools to force a refresh of both (I think). Not necessarily useful. Sometimes not being noticed is nice.
Alright, eBay links updated from the obsolete and no longer working rover.ebay.com ones to something that should function! And in the process, eBay tracking pixels removed. Because there’s just no point.
After having removed the Javascript and lazy-load stuff, I realized, poking around in the console, that the thumbnails for “related posts” and “previous/next post” and such weren’t actually the lower res thumbnails I produce for exactly those purposes. They were the full res images… several megabytes each, typically. Whoops.
I’ve fixed that (webp images are now typically in the 150-600kb range - being an image heavy blog, I can’t really skip the images bit), and total page load sizes should be substantially reduced. The search json is still huge (1.6MB compressed), but at least is pretty well static and loads after other stuff, and should generally remain cached after one load.
Let me know if you catch anything not behaving as described. Thanks!
Further improvements percolating through: I’m now using the browser-native lazy loading tags on at least most of the images in the post, which should allow for lazy loading benefits on browser that support it, without requiring JS.
I’ve also, for no reason beyond “May as well,” added the “defer” attribute to my remaining Javascript.
Should improve performance on loads, at least slightly.
Continuing down the “Where can I extract performance?” path, it turns out that CloudFlare, by default, doesn’t cache all files…
The Cloudflare CDN does not cache HTML by default.
Huh. So, I created a rule to cache everything, and tweaked a few other settings while I was in there. My blog is literally static. You can cache everything.
Results? A rather significant improvement in cache hits and data cached! New page loads are running in the 70% range vs about 5%.
This has corresponding impacts on how much is being served directly from CloudFlare, and how much comes off my server - which, even though I’ve got good upload on that box, it’s still more latency in the loop. Not going to pay for Argo routing, sorry.
So, continuing improvements. Better performance for end users, less bandwidth for me, seems a win!
How will this interface with changed or updated content? Does it poll every so often for changed content behind the cache, or do you poke it?
Haven’t changed content since I made those changes, but I believe the method I normally use, which is a load of the page, followed by shift-refresh, will update things properly. Otherwise, I’ve got a button in Cloudflare to blow the cache entirely and update it I can use if I need it.
I have added a thing!
http://sevarg23xsfkbxg5qdxa2jrrwik4ebbgfdbwuo3jhb5fznjk2usjldqd.onion
I may set that as the canonical Tor URL for the site here in the headers soon enough, just to help support the Tor network.
Ok, there’s an onion-location meta tag in the HTML now (you can set it there or in the browser headers, and I’m not sure how the Cloudflare cache mutates headers, if it does).
If you’re using the Tor browser or something else aware of that meta tag, you should get asked if you want to redirect to the Onion version. Let me know if it’s annoying, but it seems worth doing and shouldn’t bother anyone but people already using Tor.
I’ve also uploaded some changes that move the bulk of the thumbnails and such into picture sets - which should allow for some better handling by clients and use of webp instead of jpeg.
Opinion question: Should I bother with AVIF at this point? I can do it, it’s just exceedingly slow to render.
Tor support improved. Formerly, if you went to a random page (such as the iOS Lockdown report page), the header would redirect you to Tor… to the root site. It now properly redirects you to that page on the Tor site.
