Website Crisis and opportunity
If we had to pay for the amount of data downloaded every time we accessed a website, the internet would soon die out. In 2024, median page weights had risen to a whopping 2'500'000 bytes.
The more it weighs the longer you wait and (according to Google) 53% of mobile users wait a maximum of 3 seconds before leaving.
It's not just the waiting time. Heavy pages make your device do more work, causing shorter battery lives, inflated data plans and immense ecological damage. But it doesn't have to be this way.
This website was built on a framework-free platform that delivers the minimum of resources required for you to engage with the content. The ugly little button at the top of the screen shows how much data in kilobytes was downloaded to your device.
Clicking the button shows a chronological record of each resource transferred to your device. The list is not static, though. As you scroll through the content more resources are downloaded. For example, if you tab away from this page and return a BEACON resource will appear at the bottom of the list - it's Javascript code sending an anonymous record of your visit to a database.
Let's start with images
Images are compressed and delivered in optimal format for modern web browsers. For example, this image compresses from its original size of 1MB to about 20K.
While not perfect, it's perfectly acceptable for most viewers.
If you are viewing this on a mobile phone, it will weigh even less. Images are configured so that the browser can select the best sized image for your device's dimensions.
Fonts
This website uses the Roboto Serif font for headings and the Asap font for text (both available at zero cost from Google).
Instead of downloading the complete fonts to your browser, we only download those characters and styles actually used in the content - the difference is about 250K less data.
Cascading Style Sheets
This site sends about 8K of CSS, which is far too much and will be reduced to half that once we work out how to deliver page-relevant CSS.
Javascript
About 10K of Javascript was downloaded to your device after the content was rendered. It captures details about your experience on the site including how long it took to download, the page weight and other metrics like how long you were engaged on each page.
These are all sent back to a database for the site owner to understand how real users experience the site. This is called Real User Monitoring and is the basis for making informed decisions on how to improve the content.
Javascript Modules
The hamburger menu includes a Log in button so that site owners can log in and change any of the content using an inline What You See Is What You Get editor.
Actually, it's not this specific site they edit, but its companion editor site.
Owners change and pubish the content of the editor site until they like the results and then click "Publish Live Site" to replicate all of the content.
In this way, the domain name and an email for authentication is all that's needed in order to independently maintain your website. No need for a password. No need to sign in to another application. The domain and editor application are conjoined.
There's a lot of functionality required to edit a website - you need code for the owner to select and download fonts from Google for example. You need code to save every content change to a database, plus a whole lot more code to assemble the required resources and publish the website.
The important point is that you should never have to load all that code all of the time every time you want to change something. Javascript modules allow us to design complex web applications in such a way that the user only downloads the Javascript they actually need.
It's a similar approach to how we subset fonts to include only the styles and characters actually used in the content and is completely different to how Javascript frameworks and the wordpress plugin ecosystem send every first time visitor multiple megabytes of code to compile and execute.
Security
The three bedrocks of the website building platform are:
- Performance
- Accessibility
- Security
Performance is measured in how long you waited to engage with this page and is recorded in the dropdowns available top right. If you waited more than 2 seconds and you're not on a 4G connection then I'm obviously talking bollocks and you should leave.
Accessibility means that the depressingly large number of people with disabilities are also able to experience the content, perhaps using assistive technologies. It also means that your site is legitimate as governing bodies start introducing legislation that public facing websites conform to established accessibility standards.
When you have a full editing application one login away from the world of internet users, you had better be sure that no one can hack in to your system and delete your web site unless you don't pay a ransom.
For this reason the platform does not use cookies or passwords.
When you log in, as the owner for example, you have to authenticate using something known personally to you like your email account. It's entirely up to you how you secure your email - password, two factor authentication, screen saver, biometric passkeys - there's lots of ways to secure your email.
The important point is that when you do authenticate through your email - either copy/pasting a random 6-digit code or clicking on a link - your unique identity is encrypted in tokens created on the server and subsequently stored on your browser.
You get two encrypted tokens, a refresh token and an access token. The refresh token serves only to request a short-lived access token which accompanies every change request. Every change request made in the editor includes the access token which is checked by the server before executing the change.
The access token expires after 5 minutes after which it is automatically refreshed by the server. So, if someone was able to steal your access token they only have 5 minutes to do any damage before it expires.
If they manage to steal your refresh token, an additional fingerprint check is made by the server to ensure it's been sent from a known, previously authorized, combination of browser identity plus IP address. The attacker would have to log in again if this was the case and can only do so with the site owner's email account.
Of course, if someone other than the owner takes the owner's device in the last location from which they successfully performed an edit and their email isn't secured, then all bets are off.
As it happens, there's no realistic way that anyone externally can steal your tokens because all sites are created with a strict Content Security Policy.
Content Security Policy
Every web page is downloaded with a strict Content Security Policy. This effectively disables the most common forms of attack - cross site scripting for example is impossible because the policy prevents ALL javascript from executing unless it has been signed.
When the owner clicks "Publish Editor Site", the server creates each page with an integrity hash on the startup Javascript code, meaning that browsers will only execute Javascript if it has been signed with this hash code.
You can see for yourself at the Security Headers web site.
Compare this page's security rating with a Wordpress site to see the difference.
User Experience
Web pages should deliver optimal utility at minimal cost, where "cost" is measured in terms of real user performance.
As well as information value, user experience is primarily based on how quickly the content can be accessed - the single most important factor in this is how much data the server sends to the client's device.
A modern, responsible website builder focuses primarily on the end user's experience, while website owners can expect all of the following as standard features:
- 100KB maximum data downloaded to first time visitors
- 90% of pages loading in less than 2 seconds by first time visitors
- 90% of pages rating "good" for Google's Core Web Vitals
- data sent only when requested and actually needed
- accessible content that scales to all visitor devices
- real-time access to website analytics
- real visitor metrics like engagement and patterns of use
- secure from threat of hackers
- secure from misuse in case of theft
- independently publish content of editor and live websites
- inline feature-rich content editor
- choice of all Google fonts
- content backed up every day
- ability to download all website assets at any time
Try downloading a website from Wix, for example, to see an example of lock-in.
Fonts should look great
The editor offers italic and bold styling -
Normal
Normal bold
Italic
Italic bold
However, not all fonts provide italic and bold styles. If your chosen font does not support italics, then browsers by default artificially slant the characters. Same thing if your font doesn't support bold characters - the browser will artificially bolden the characters.
Faux styling like this looks ugly and greatly diminishes the reader's experience.
So what we do in these cases is animate faux-styled text.
In order to stop the annoying animation either remove the italic / bold styling in the editor or choose a font that does support the styles you want.
Optimising Fonts
Most web pages are over 2MB in weight.
Font files contribute a lot to page bloat when all of the font's available character set is downloaded. Websites, however, typically use only a small subset of the full character set.
My sister's website, for example, has 80 pages comprising over 30'000 words but uses only 78 distinct characters - by creating a version of her selected font limited to only these characters, her site visitors download a fraction of the full font file (i.e. 15K compared to 150K).
In this way, the visitor pays a minimum in terms of data transfer in order to view the content. Think of each KB downloaded as a cost to both the visitor and the environment; a cost which increases as more pages are viewed on mobile networks and devices.
The other beneficiary is the site owner - smaller pages load faster which Google appreciates by crediting the website in its ranking algorithm. Sister's website was migrated to this platform from Wordpress in 2024; after a few months it rose to the top of Google's ranking for the relevant keywords and now gets almost 1000 first-time visitors a month (compared to 40 on Wordpress).
Real User Monitoring
When a website page is downloaded to a visitor's device a background process captures details about their experience, one of the most important being how long they had to wait before being able to view the content.
An equally important metric is how long they engaged with the content.
Was this the first time they visited the page? Which pages did they visit and in which order? How were they referred to the site? How much data did the visitor have to download? Was the content stable? How responsive was the page to interactions? What was their connection speed and where did they connect from?
Real User Monitoring is about collecting all of these details so website owners can measure how their site is experienced by real users and thereby make informed decisions to improve it.
Is this thing offered commercially?
Most certainly not.
Our goal is to encourage people to build websites that are orders of magnitude more performant and secure, whilst still offering a reasonable degree of design flexibility.
There's a lot you can do with typography, for example, to bring great personality to a site. By varying font colours, sizes and styles you can almost deliver magazine-style design to your pages.
Presently we only support two different fonts - one for headings and one for text - that is, everything else. However, it would be trivial to allow different font choices for code blocks, blockquotes, even different fonts for different heading levels.
The only cost involved in making this thing more widely available is the database server. Currently we use a free Oracle Cloud database but that wouldn't be happy supporting more than a few concurrent users.
To extend this to a wider audience we propose sharing database server costs based on actual CPU usage. If we could get a decent server for about 200 USD / month, then we could charge that at an average of 2 USD / month if we had 100 subscribers.
We reckon that's the most equitable way of moving this forward. If you subscribe and don't use it or no one visits your site, then you pay nothing. If you go mad and use 10% of all CPU consumed and get hundreds of first-time visitors a day then you would pay 20 USD / month.
That's still way cheaper than most "plans" offered by commercial players.
Would be interested to hear what you think.