Last week I decided to try something interesting. I opened my blog up in Cursor and asked for a basic performance review. That seems like a no-brainer, but keep in mind, my blog's source code clocks in at near seven thousand files (ignoring node_modules of course), so this wasn't some small request.

My blog is built with the Eleventy static site generator. It's a mix of JavaScript and Markdown primarily, with a huge portion of the codebase being Markdown and not 'code' per se, but me rambling on about cats and Star Wars. There's also Liquid templates which are parsed into HTML by a JavaScript library. But that doesn't quite tell the whole story.

In Eleventy, when converting my Markdown into HTML, it also applies the Liquid template syntax to Markdown which means my blog posts can actually be dynamic, at build time anyway. This impacts how fast the site builds in ways I can completely forget about down the road.

This is why I let Cursor look over the entire code base instead of ignoring my Markdown (Cursor docs on ignore files), and I'm glad I did. I'll share the complete report at the end of this post, but let me talk about the highlights.

RSS Parsing and a dead Mastodon server

The biggest fix Cursor discovered concerned code I had to work with, and render, Mastodon posts. I've got a shortcode that given a server and username will find the last post via the RSS feed generated for the account. I use another shortcode that renders the post into HTML.

Cursor discovered I had multiple calls out to botsin.space, a Mastodon server that was built to target bots and unfortunately had to be shut down. I had multiple blog posts trying to get content from that server. The code, which made use rss-parser, would get a quick failure but was keeping an HTTP socket open until it timed out, roughly 70 seconds later.

To be clear, the 'bug' here was in my implementation, not the RSS library. The fix was pretty simple. Going from:

import Parser from 'rss-parser';

const parser = new Parser();

To:

import https from 'https';
import Parser from 'rss-parser';

const parser = new Parser({
  requestOptions: {
    timeout: 5000,
    agent: new https.Agent({ keepAlive: false }),
  },
});

This alone helped, but I also found instances in my Markdown where I was calling out to botsin.space and replaced it with mastodon.social (where I moved my bots).

Trying to be AI friendly had an unintended consequence

A few months back I made a change to my blog to be more AI friendly. That involved two steps:

• For every post, I now have a copy of the Markdown version. So for example, this https://www.raymondcamden.com/2026/07/06/my-new-role-helping-ai-adoption-at-cursor goes to HTML, and you can go to https://www.raymondcamden.com/2026/07/06/my-new-role-helping-ai-adoption-at-cursor/index.md for the Markdown
• I used a Netlify Edge serverless function to sniff for a content request that prefers plain text or Markdown, what an AI agent would send, and redirects to that automatically. You can see that code here: https://github.com/cfjedimaster/raymondcamden2023/blob/main/netlify/edge-functions/content-negotiation.ts

To enable the Markdown copy, my eleventy.config.js uses an event handler for builds:

eleventyConfig.on("eleventy.after", async ({ dir }) => {
    const inputDir = dir.input;   
    const outputDir = dir.output; 

    // blog posts only
    const mdFiles = glob.sync("posts/**/*.md", {
        cwd: inputDir,
        ignore: ["node_modules/**"],
    });

    for (const file of mdFiles) {
        const srcPath = path.join(inputDir, file);
        /*
        My input file looks like so:
        src/posts/2026/03/04/2026-03-04-dyanimically-adjusting-image-text-for-contrast.md
        I need to save to

        outputdir/2026/03/04/dynamically etc
        */
        let newFile = file.replace('posts', '');
        newFile = newFile.replace(/[0-9]{4}-[0-9]{2}-[0-9]{2}-/,'');
        newFile = newFile.replace('.md','/index.md');

        const destPath = path.join(outputDir, newFile);


        fs.mkdirSync(path.dirname(destPath), { recursive: true });
        fs.copyFileSync(srcPath, destPath);
    }
});

The important bit is the glob. When I run my blog locally, I have an .eleventyignore file which ignores blog posts from 2003 to 2024 or so, basically 90% of my blog posts (I blogged a lot more in the old days). However, my glob wasn't using that and every change resulted in 6k+ files being copied. Locally that meant every change I made while writing a post would take about 3 seconds to process. That's not bad in theory, but I tend to write, check the HTML, edit, etc, quickly, and I absolutely noticed times when I'd have to reload again because I reloaded too quickly the first time.

For the fix, I went back to Cursor and simply asked for help and the response was perfect:

I missed this in Eleventy's docs on the event that's 100% on me. I let Cursor update the code:

eleventyConfig.on("eleventy.after", async ({ directories, results }) => {
    const inputDir = directories.input;
    const outputDir = directories.output;

    // Only copy posts Eleventy actually built (respects .eleventyignore)
    const postResults = results.filter((r) => {
        const rel = path.relative(inputDir, r.inputPath);
        return rel.startsWith(`posts${path.sep}`) && rel.endsWith('.md');
    });

    // rest of event...

Bypassing API calls locally

One last thing it suggested that I implemented involved my _data files. These files use remote APIs to fetch data for my site, most of which you can see on my Now page. I had code to look for a local run, or a lack of an environment variable for a key. My code though was a bit of a hack, like looking for /home/ray, and that failed on new machines where my local username didn't match. It didn't dramatically impact my builds, but Cursor pointing this out made me build a nicer solution - which was just to look for an environment variable instead, one I include in my npm scripts now:

"dev2": "SKIP_REMOTE_DATA=1 eleventy --serve --quiet",

(The use of 'dev2' is another story and related to a bug in the Netlify CLI.)

Wrap Up

Ok, I work at Cursor, I'm biased, but of course other tools could create similar results. I'm just impressed by how deep Cursor looked into my code and found things that I never would have realized. As I write this and save, I'm seeing build times of 0.33 seconds or so, which is freaking great. My "full" builds aren't necessarily faster, but that's fine. (Netlify and Eleventy both perform incredibly well with a typical site build of less than four minutes.)

Here's the complete initial report Cursor created.

Photo by Yannik Zimmermann on Unsplash