About

One thing I often found myself thinking about while using various CMS platforms was how they handled CSS.
In most cases, styling options were limited to dropdown menus or numeric fields, often allowing only pixel values.
If I wanted to use modern CSS features such as clamp(), calc(), min(), max(), or CSS variables, I usually had to open a separate CSS editor. At the time, I couldn't understand why I wasn't able to write CSS directly while looking at the page I was designing.

Every time I had to move a website, I found myself doing the same things all over again.
Whenever I used WordPress or Movable Type, migrating a website always felt like more work than it should have been.

First, there was the database server to prepare. Then the data had to be exported and imported, sometimes with the help of migration tools. Domain settings often needed to be changed, and moving the site into another directory usually meant even more configuration.

Maybe it was just me, but my memory was never good enough to remember every step. Every time I had to migrate a site, I ended up searching the web for the same information all over again.
So I wanted to build a CMS that was easier to move.

I wanted it to work wherever it was installed, whether that was on another domain, in the document root, or several levels down in a subdirectory.
The moment it was installed, that location would become its new center.
Suppose I uploaded it by FTP to directory A, then realized it should have been directory B.
I wanted to rename the directory and have the CMS start working there immediately.

I wanted to be able to upload and display GLB models directly from the CMS. Three.js has been around since 2010, but to me, it feels like web-based 3D really started taking off around the time the metaverse became a big topic during COVID. Sometimes I catch myself thinking... "Maybe websites won't always be just HTML." Maybe one day, visiting a website will become more about the experience than simply reading a page.
Lately, I've been thinking that Web 5.0 might be all about experiences.

That's one of the reasons I wanted to add 3D support to the CMS.
Right now, it only supports displaying GLB models.

But I think that's a good place to start.

If someone wants to improve the lighting, add better controls, or build something even more advanced, I'd love to see what they come up with.
One of the reasons I feel this way goes back a few years.
I built a trade show booth simulator.
While I was working on it, I kept thinking...

"3D on the web is going to become much more important." I originally built this feature almost just for fun.
But then I realized something.

If all you want to do is let people view a 3D model on your website...
You don't really need an external service anymore.
That's exactly why I wanted it built into the CMS.

This is the background behind why I developed a CMS that I myself can use comfortably. Why does this CMS insist so strongly on lightweight design? And why did I decide to build it in the first place? I want to explain these reasons through the lens of 30 years of web history and today’s internet reality.

Around thirty years ago, when the internet first began to spread, dial‑up connections were the norm. For web creators, the biggest challenge was how to make pages load as fast as possible. Compared to that era, today’s computers are a thousand times faster, and internet connections are a thousand times wider. Yet the core elements of the web—HTML, CSS, images, JavaScript—haven’t changed much. In theory, websites should now load at near‑instant speeds. But reality took a different path.

As CMS platforms became widespread, websites grew more layered and complex. Images that once took minutes to load are now sent casually at ultra‑high resolution. Parallax effects and heavy animations became common—even when they don’t improve usability. Sometimes it feels like highlighting text in red to make it stand out, then turning the entire page red. High‑resolution images aren’t inherently bad, but the trade‑off often hurts more than it helps. In many cases, speed matters far more than visual perfection.

Over the past thirty years, browsing shifted from PCs to smartphones. Displays evolved into high‑density Retina screens capable of stunning visuals. But user expectations changed too. People care less about image quality and more about reaching the information they want—fast. No matter how beautiful an image is, most users scroll past it in seconds. What truly matters is how quickly they can reach the content they came for.

With AI accelerating global traffic, internet load has become a serious issue. When delivering a website, images—not HTML—dominate bandwidth usage. Changing image formats alone can reduce load time by one or two seconds. At global scale, that one second becomes enormous. Lightweight design is no longer just a preference—it’s a responsibility.

This CMS adopts WebP as the standard format. AVIF is even lighter and will likely become the future standard. But as an MIT‑licensed CMS, I cannot force server environments on users. AVIF conversion doesn’t work on PHP 8.1 or below, and many rental servers still run 7.x or 8.0. Forcing AVIF would burden users, so WebP is the practical choice for now. When server environments catch up, the CMS will fully transition to AVIF.

HTML optimization was one of the toughest challenges. I wanted to eliminate unnecessary nesting and keep everything as simple as possible. The editor was the hardest part. Images required a

element, resulting in five layers: section → .inner → div → figure → img. Everything else stays within three layers. I chose

for reasons that will become clear in version 2.0. Without that purpose, I could have reduced it to two layers. The first editor I built was too clumsy, so I rebuilt it entirely right before release. After testing it on a real client’s site, I was surprised by how smooth the workflow became. This CMS is easy for developers who understand HTML/CSS, but may feel advanced for beginners. It’s intentionally built for web creators—not general users.

This CMS was built with PageSpeed Insights in mind. When I started computing, I used a PC‑9800mkⅡ notebook with 2MB of RAM (later upgraded to 4MB), a 40MB HDD, and a monochrome display. Even under those constraints, applications fit on a single floppy disk and ran smoothly. Today’s computers are thousands of times more powerful, yet modern OS and apps are thousands of times heavier. My challenge was to see how far I could push simplicity in a CMS. I believe PageSpeed Insights is Google’s way of saying: “Let’s reduce global internet traffic.” With roughly 1.6 billion people using the web every minute, saving even one second per person has massive global impact.

Recently, I attended a meeting of small‑business owners. I asked them who manages their websites. Every single one said they rely on external contractors. Some still use HTML from twenty years ago, without responsive design. No one can update those sites, so they remain frozen in time. That moment confirmed that my CMS was heading in the right direction.

This CMS does not include: • customer management • sales management • mail forms • access control Some may say, “That makes it a weak CMS.” Honestly, I sometimes think so too. But are those truly CMS features? Customer management has dedicated systems. Sales management has dedicated systems. Mail forms differ by server. Even WordPress relies on plugins. So why not let each environment use the tools best suited for it? This CMS doesn’t aim to do everything. It aims to make web creation simple, fast, and free. Users can customize anything. This CMS is for creators who genuinely care about lightweight design. Over time, it will evolve into your personal CMS. A 1MB CMS—experience what lightweight truly means. I look forward to your review.