# A small blog that answers questions about itself. Source: https://fengyiqicoder.github.io/eleventy-ai-starter/ These are notes on running a personal site with a static generator: why it is worth it, how the writing gets from a text file to the web, and how to keep the site quick and easy to find. This site is the Eleventy AI starter. Every build writes an llms.txt and an llms-full.txt, and the Ask button at the top answers from them. Try "How do I publish a draft?" ## Recent writing Source: https://fengyiqicoder.github.io/eleventy-ai-starter/#recent 1. Keeping a small site fast and easy to findOct 14, 2026 Page weight budgets, fonts, feeds, sitemaps and llms.txt. The short list of things that keep a static blog quick and discoverable. 2. Writing in Markdown, publishing with gitSep 23, 2026 How a post goes from a text file to the live site, including drafts, images, and fixing a typo from a phone. 3. Why I moved my blog to a static siteSep 02, 2026 A database-backed blog cost me money, time and two security scares. A folder of HTML files costs nothing and has not broken once. All posts Browse by tag About this site # About Source: https://fengyiqicoder.github.io/eleventy-ai-starter/about/ Small Static is a blog about running a small website without a server. It covers the parts that come up again and again: picking a generator, writing in plain text, publishing with git, choosing a host, and keeping pages fast and easy to find. The posts are written for people who want a personal site they can keep for ten years. That usually means fewer moving parts, not more. ## How this site is built The site is made with Eleventy. Posts are Markdown files in `src/posts/`. Running `npx @11ty/eleventy` turns them into plain HTML in the `_site` folder, and that folder is what gets uploaded. There is no database and no server code. The styles are one small CSS file that is inlined into each page, and there is no JavaScript of its own. Every build also writes: - an Atom feed for feed readers, - a sitemap for search engines, - an llms.txt that lists every page with a one-line summary, - an llms-full.txt with the text of every page in one Markdown file. ## The Ask button The Ask button in the header opens a box where you can type a question about this blog. It reads `llms-full.txt`, picks the passages that match the question, and writes a short answer with links to the posts it used. The answer comes from OneTag AI through a single script tag, so the site itself stays static. If you want to know what the box can answer, ask it something the posts cover: which hosts are free, how drafts work, or how big a page should be. ## Using this starter This site is a template. Clone it, change the title in `src/_data/site.js`, replace the three posts, and deploy. The README explains each step. # Posts Source: https://fengyiqicoder.github.io/eleventy-ai-starter/posts/ Everything written here, newest first. There is also an Atom feed. 1. Keeping a small site fast and easy to findOct 14, 2026 Page weight budgets, fonts, feeds, sitemaps and llms.txt. The short list of things that keep a static blog quick and discoverable. 2. Writing in Markdown, publishing with gitSep 23, 2026 How a post goes from a text file to the live site, including drafts, images, and fixing a typo from a phone. 3. Why I moved my blog to a static siteSep 02, 2026 A database-backed blog cost me money, time and two security scares. A folder of HTML files costs nothing and has not broken once. # Tags Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/ Posts grouped by topic. - hosting 1 post - performance 1 post - static sites 2 posts - workflow 1 post - writing 1 post # Keeping a small site fast and easy to find Source: https://fengyiqicoder.github.io/eleventy-ai-starter/posts/fast-and-findable/ October 14, 2026 2 min read Page weight budgets, fonts, feeds, sitemaps and llms.txt. The short list of things that keep a static blog quick and discoverable. A static site starts out fast. It stays fast if you avoid adding weight you do not need, and it gets found if you publish a few small files that machines know how to read. This post is the checklist I use. ## Set a page weight budget Decide how heavy a page is allowed to be and check it now and then. For a text blog, 100 KB for the HTML, CSS and fonts together is generous. This site inlines its CSS, uses the reader's system fonts, and ships no JavaScript of its own, so a post is about 15 KB before images. The usual causes of a slow blog are easy to spot: - Web fonts. Each weight and style is another file. If you want a custom font, host one variable font file yourself and preload it. Or use the system font stack and skip the download. - Large images. Resize them before you commit them. Add `width` and `height` so the page does not jump while they load, and `loading="lazy"` for anything below the first screen. - Third-party scripts. Analytics, embeds and chat widgets often weigh more than the rest of the page. Load the ones you keep with `async` so they never block the text. ## Make it readable without effort Speed is not only bytes. A line length of 60 to 75 characters, a font size of at least 17 pixels and enough contrast between text and background make a page faster to read. Support dark mode with the `prefers-color-scheme` media query, so the site follows the reader's system setting with no toggle to build. ## Publish files that machines read A few small files do most of the work of being found: A sitemap. `sitemap.xml` lists every page with its address and date. Search engines use it to find new posts sooner. Submit it once in Google Search Console and Bing Webmaster Tools. A feed. An Atom or RSS feed at `feed.xml` lets readers follow the blog in a feed reader. It is still how many people keep up with small sites, and it costs nothing to generate. Good titles and descriptions. Each page needs a unique `` and a `meta` description of one or two sentences. These are what people see in search results, so write them for people. llms.txt. This is a newer convention: a Markdown file at the root of the site that lists the pages with a short summary of each, for AI tools that read the web. Its companion, `llms-full.txt`, holds the full text of every page in one file. This starter writes both at every build from the finished HTML, so they never fall out of date. ## Let readers ask `llms-full.txt` has a second use. The Ask button on this site sends a reader's question, together with the matching parts of that file, to a language model and shows the answer with links to the posts it came from. It is one script tag loaded with `async`, so it does not slow the first paint, and it only fetches the text when someone opens the box. ## Check it now and then Run Lighthouse in Chrome's developer tools on your home page and one post every few months. It measures speed, accessibility, best practices and search basics, and it tells you exactly what to fix. A small static blog should score at or near 100 in all four without special tricks. Filed under performance, static sites # Writing in Markdown, publishing with git Source: https://fengyiqicoder.github.io/eleventy-ai-starter/posts/markdown-and-git/ September 23, 2026 2 min read How a post goes from a text file to the live site, including drafts, images, and fixing a typo from a phone. The workflow for this blog fits on an index card: write a Markdown file, commit it, push it. A build server does the rest. Here is what each step looks like in practice, and the few habits that keep it smooth. ## One file per post Each post is a file in `src/posts/`. The file name becomes the address, so `markdown-and-git.md` is published at `/posts/markdown-and-git/`. Pick the name with care, because changing it later breaks links. At the top of the file is a short block called front matter: ```yaml --- title: Writing in Markdown, publishing with git description: How a post goes from a text file to the live site. date: 2026-09-23 tags: [writing, workflow] --- ``` The title and description show up in the post list, in search results and in the feed. The date sets the order. Tags group posts on the tags page. Everything below the second `---` is the post itself. ## Drafts A draft is a post that is not ready to be seen. The simplest way to keep one is a git branch: write on a branch called `draft-whatever`, and merge it when it is done. The live site is built from the main branch only, so nothing leaks. If you prefer to keep drafts next to the finished posts, add `draft: true` to the front matter and tell Eleventy to skip those files in production. Either way works. The branch is harder to publish by mistake. ## Images Put images next to the post or in one `images` folder, and keep them small. A photo straight from a phone is often 4 MB. Resized to 1600 pixels wide and saved as WebP or a compressed JPEG, it is closer to 200 KB and looks the same on screen. Always write alt text that says what the image shows, not what it is called. ## Publishing When the post is ready, commit it and push: ```sh git add src/posts/markdown-and-git.md git commit -m "Post: writing in Markdown" git push ``` The push starts a build on the host. On GitHub Pages that is a workflow file in `.github/workflows/`. Netlify, Vercel and Cloudflare Pages watch the repository and build on their own. A minute later the post is live. ## Fixing a typo from a phone Because the posts are text files on GitHub, you can edit one in the GitHub web editor or app, commit there, and the same build runs. This is the feature I did not expect to use and now use every week. ## Keep the habits small Write the description before the post; it forces you to know what the post is about. Read the post once in the browser before you push, since Markdown hides some mistakes until it is rendered. And commit often. A git history is the best undo button a writer has ever had. Filed under writing, workflow # Why I moved my blog to a static site Source: https://fengyiqicoder.github.io/eleventy-ai-starter/posts/why-static/ September 2, 2026 2 min read A database-backed blog cost me money, time and two security scares. A folder of HTML files costs nothing and has not broken once. For six years my blog ran on a hosted CMS. It worked, mostly. Then the bill went up, a plugin I relied on stopped getting updates, and I spent a Sunday restoring the database after a bad upgrade. That was the week I started moving it to a static site. ## What "static" means here A static site is a folder of finished HTML files. A program called a static site generator builds that folder from your writing, once, on your own machine or on a build server. When a reader asks for a page, the host sends the file that is already there. Nothing is assembled per visit, so there is nothing to crash per visit. The generator I use is Eleventy. Others like Hugo, Jekyll and Astro work the same way. The choice matters less than people think. What matters is that the output is plain files you can move anywhere. ## What I gained It costs nothing to host. GitHub Pages, Netlify, Cloudflare Pages and Vercel all serve a small static site for free. My old host charged twelve dollars a month for the same traffic. It is fast without trying. There is no database query and no server-side rendering between the reader and the page. The home page of this blog is under 20 KB, and it loads in well under a second on a slow phone connection. There is less to attack. No login page, no admin panel, no plugin with a known hole. The worst thing someone can do is read the posts, which is the point. The writing is mine. Every post is a Markdown file in a git repository. I can read them with any text editor, search them with `grep`, and keep them long after any particular tool is gone. ## What I gave up Some things need extra work on a static site. Comments need a third-party service or a mailing address. Search needs an index built at build time. A contact form needs a form service. None of these were hard to add, but they are not free in the way a CMS makes them feel free. The other cost is the build step. You change a file, then the site has to be rebuilt and uploaded. In practice a push to GitHub does both in under a minute, so I no longer notice it. ## Would I do it again Yes. The site has been on a static host for over a year. It has not gone down, it has not needed an update, and it has not cost anything. The time I used to spend on maintenance now goes into writing, which was the reason I had a blog in the first place. Filed under static sites, hosting # Tagged hosting Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/hosting/ All tags 1. Why I moved my blog to a static siteSep 02, 2026 A database-backed blog cost me money, time and two security scares. A folder of HTML files costs nothing and has not broken once. # Tagged performance Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/performance/ All tags 1. Keeping a small site fast and easy to findOct 14, 2026 Page weight budgets, fonts, feeds, sitemaps and llms.txt. The short list of things that keep a static blog quick and discoverable. # Tagged static sites Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/static-sites/ All tags 1. Keeping a small site fast and easy to findOct 14, 2026 Page weight budgets, fonts, feeds, sitemaps and llms.txt. The short list of things that keep a static blog quick and discoverable. 2. Why I moved my blog to a static siteSep 02, 2026 A database-backed blog cost me money, time and two security scares. A folder of HTML files costs nothing and has not broken once. # Tagged workflow Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/workflow/ All tags 1. Writing in Markdown, publishing with gitSep 23, 2026 How a post goes from a text file to the live site, including drafts, images, and fixing a typo from a phone. # Tagged writing Source: https://fengyiqicoder.github.io/eleventy-ai-starter/tags/writing/ All tags 1. Writing in Markdown, publishing with gitSep 23, 2026 How a post goes from a text file to the live site, including drafts, images, and fixing a typo from a phone. <!-- generated by static-llms-txt -->