Following on from the previous release, which was all about trying to get a big PageSpeed Insights win through image optimisation, I'm chasing some more validation from that site by trying to squeeze just a little more performance out of the code that BlogMore generates.
BlogMore v2.25.0 has the following changes to allow tinkering in ways that might speed things up a touch, depending on the nature of the blog:
CSS bundling -- Every page generated by BlogMore pulls in at least these three CSS files: style.css, code.css and fontawesome.css (or their minified versions if minify_css is turned on). While this separation of concerns sits well with me, while it feels like the elegant way of doing things, there is the issue that it requires 3 trips back to the server to get base styling for any given page1.
So with this new version, if you set bundle_css to true, those three files are included and delivered as a single bundle.css (or bundle.min.css). This saves a couple of requests.
Theme helper inlining -- the lesser of the two main changes. There is some JavaScript that's part of each page that helps with theme switching and also provides the code to toggle the header display on mobile-sized screens. It's not a lot of code, but it is another file that has to be fetched. If inline_theme_js is set to true, this code will be included in the <head> of every single page generated for the site.
I suspect I'm going to leave this one off, but it's there if it's helpful to anyone (and also does let me experiment more with PageSpeed measurements).
Optimised logo -- one image that got left out of the work to optimise images was the site logo. While an optimised version of the image was created, no HTML was generated to make use of it. With this release, if optimise_images is true, <picture> will be used for this too.
With those shameless performance-measurement changes aside, there are a couple more changes in this release. The first is that the markup for the site title (that appears below the logo, if you have one) has been changed away from using a <h1> tag. The SEO gods frown on multiple <h1>s on a page and given the "main" title of any page is also a <h1>, this meant there were always 2 such tags. Now just the main title will be marked up this way; the site title becomes a <div> with appropriate styling to maintain the existing look.
Finally, this release fixes a small bug in the search index. It was being created with escaped HTML entities in any text that came out of fenced code blocks. From now on any text that goes into the search index is unescaped.
As always: if a blog-oriented static site generator that is all about Markdown sounds like your thing, check out the installation instructions and give it a go.
Yes, of course the client-side cache makes this moot after the first page is loaded. All of this is about making that first load faster, and so appeasing the PageSpeed Insights gods. ↩
Well, what a surprise, nobody could have seen it coming: it does seem to be bait and switch season in LLM/agent land.
As I mentioned earlier today, when I ran up Gemini CLI to have it work on a change to BlogMore in the background, I got a notification that I should be swapping to Antigravity CLI instead. I let Gemini CLI get on with the change anyway, but resolved to install Antigravity CLI and give it a go. While there's still a touch under a month of use of Gemini CLI to go (based on the blog post), it seems sensible to get to know the new tool as soon as possible.
Installing Antigravity was a little bit of a faff. Looking at the documentation, you have to install the main application itself first, authorise with that, and then you can install and use the CLI. Fair enough. Rather than download the DMG from their website, I decided to go with the Homebrew installation (I like to try and keep track of what I have installed and this helps me do that).
So I installed that, ran it up, went through some setup questions, then finally got dropped in something that looked like it wanted to be an IDE of sorts. Nah, I'm fine, I like to work elsewhere. But that was okay given that I just wanted to get to the CLI anyway. Before I did that though, having installed this app, I saw that it was showing a "Restart to update" notification. So I did that, waited a wee while, and then finally was presented with something that looked totally different. Now I had an application that looked almost exactly like the main Gemini website (or the Gemini macOS application).
So that was kind of weird.
Finally I was in a position to install the CLI itself. From what I can see it's not available via Homebrew yet, and the installation instructions are the usual "curl this through bash, trust me bro" affair. Having done that (yes, yes, I know...), I was all set.
Credit where it's due, when I ran it up it just worked. As in: I didn't need to authorise again or anything like that; the fact that I'd set everything up via the main application did seem to have done that job.
After this though, it kind of went a little downhill. The first thing I noticed was the set of models available was rather different from Gemini CLI. I mean, okay, that's fair, I guess you expect things like that to change, but in my inexperienced1 view of what these agentic tools offer, it looked like all the options were a little more... pricey, perhaps?
Still, I'm sure that sensible defaults are chosen out of the box, so it seemed like a good time to give this new tool a shot. I had a nice little problem for it to work on so that felt like a great test. It's hard to say for sure, but I feel like an issue like that, with the right prompt, would have used up somewhere between 3% and 5% of the daily quota in Gemini CLI, using Auto (Gemini 3). That was the default out of the box and, aside from tapping the models to try and unstick them, I've never really set it to anything else and the results have always been fine. With all this in mind I set Antigravity to work. Given that there didn't seem to be any sort of "Auto" option, I let it go with Gemini 3.5 Flash (High), which is what it was set to out of the box.
Yikes.
As I read that, and as I recall what happened, it took about 25 minutes to get to a reasonable solution to the request, with me pushing back on a couple of wild choices it made about how to change the code around. In doing this it left me with just 20% of the quota free for the next four and a half hours.
Yikes.
This is fine in this particular situation, where I'm conducting a long-term experiment and often letting the tool run at reasonably self-contained problems, in the background, while I get on with other more important things. But if I were to try and use this, as I have Gemini CLI, for an evening of sofa-hacking, refactoring lots of code or adding a handful of new features... that's not going to be sustainable. Any such session is going to grind to a halt pretty quickly. Presumably the intended solution here is that I buy myself lots of "AI credits".
I will experiment more, and intend to try and work out what the point, purpose and impact of each of the models are, as found in Antigravity. Doubtless there's a smarter approach I can take where it'll cost less quota for similar results. What is for sure though is that Antigravity CLI is not a drop-in replacement for Gemini CLI. It seems to be a different way of working, with different models, and different considerations. Also with less openness too.
None of this is shocking to me -- although I'll admit that I thought the Gemini CLI ride might last a wee while longer than it did -- nor, I'd hope, to anyone else, but it continues to be fascinating to watch the squeeze being applied all around this tool space. This is going to be an increasingly worse time for anyone wanting to mess with agents for hobby projects. The idea of a tool that lets you get unambitious projects done for the price of a coffee or two, per month: that was a reasonable prospect. When the real cost turns out to be similar to an actual utility bill for your home... I know some people have expensive hobbies, but this would not seem to be a rewarding one at the sorts of costs we're starting to look at.
Once again, it's going to be interesting to see how engineering departments, and AI-embracing companies as a whole, react, as they become more and more invested in these third-party services, and less able to actually do things themselves, while at the same time the suppliers of those services squeeze them harder to try and make this adventure pay off.
I say "inexperienced", but perhaps I'm being unfair to myself here. While I'm not 100%, all in, fully-steeped in agentic lore, and even though I've not been living this stuff full time for the past year or so, I do feel I'm a good representation of someone with a long background in the software development industry who is coming to these tools with reasonable expectations. ↩
I just sat down at my desk and fired up Gemini CLI to get it to make a change to BlogMore, and I see this:
I've yet to actually look at Antigravity, so I know pretty much nothing about it at this point. After a brief glance at the link that was given it seems like it's a positive change, perhaps. Honestly, I'm not sure. But that's kind of moot, I don't really have a choice. Within a month Gemini CLI is going to stop working anyway.
This is yet another reminder that, while plenty of folk are pushing these tools as the answer to the "problem" of software development, they're not really stable tools, it's not really a stable market, and, to some degree, if you fully rely on these tools, you're constantly at the mercy of the whims of some other company.
I'm glad I have a project where I'm forcing reliance on them as an experiment, so I can see and experience this first-hand, but I'd be very concerned for someone who's fully bought into them.
Perhaps there's a market here for a "Killed by AI" website, much like Killed by Google?
Or, maybe I'm being unfair here; it could be that this is more akin to Google solving the chat problem by constantly moving people from one chat application to another, while also having chat abilities in all sorts of other products...
