October 9, 2026What I Am Trying to Build With M.V. Mitic and Valentine Kingdom
When I started writing The Eternal Prince, I was primarily thinking about the story. I was not sitting there with a giant…
Website speed is easy to ignore when a site contains almost nothing. A homepage, an About page, a contact form and a page for one book do not place much pressure on a modern server. The situation changes once the same website begins handling dozens of articles, customer accounts, ecommerce, protected content, images, analytics, email systems and other features at the same time. That is where performance starts becoming part of the infrastructure rather than just a Lighthouse score. I want the website to become larger over time, which means I would rather think about efficiency while it is still manageable than wait until traffic grows and discover that every page contains years of accumulated unnecessary weight.
Small Inefficiencies Multiply
One large image is not a disaster. Hundreds of unnecessarily large images become something completely different. The same applies to plugins, scripts, fonts and database requests. Each individual item may only add a little work, but eventually all of those small decisions are happening together every time somebody opens a page. That is why I prefer keeping the software stack reasonably controlled and asking whether something actually needs to be there. If one reliable tool can handle a job, I do not want five plugins competing to do variations of the same thing. If an image can look almost identical at a fraction of the file size, I would rather serve the smaller file.
Traffic Makes Efficiency Much More Important
Scale changes the mathematics very quickly. Wasting a little bandwidth for one visitor is almost meaningless, but repeating the same waste across hundreds of thousands or millions of pageviews is not. The same applies to server processing. Public articles are especially suitable for caching because the same page can often be served repeatedly without rebuilding everything for every visitor. Account pages, carts and checkout are different because they contain information specific to the user. Understanding that difference allows the site to stay efficient without breaking the parts that genuinely need to remain dynamic. The cleaner the system is before traffic becomes large, the easier it should be to scale later.
Speed Is Part of the Experience
I also think people separate design and performance too much. A beautiful website that makes someone wait every time they click another page does not feel premium. A simple site that responds instantly often feels much more polished because nothing interrupts the visitor. The same thing matters even more for reading. If somebody opens another chapter of a book, I want the chapter to appear immediately rather than making them think about loading screens, scripts or the server behind it. Good infrastructure should almost disappear from the experience. Pages open, accounts work, payments complete and the reader stays smooth. That is why I care about performance now. I am not trying to make the site fast only for the traffic it has today; I am trying to avoid building unnecessary weight into something I want to become much larger.
