Most websites are a natural disaster
If we had to pay for the amount of data downloaded every time we accessed a website, the internet would soon die out. By 2024, median page weights had risen to a whopping 2'500'000 bytes.
The more a page weighs the longer you wait. Most mobile users will wait no more than 3 seconds before leaving.
It's not just the waiting time. Heavy pages, especially those with lots of javascript, 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 created using a modern website builder that guarantees most visitors, like you, will download less than 🌱 100KB 🌱 in less than a second.
You may already have noticed how quickly this page loaded.
If you run the url of this page on an independent performance testing platform like webpagetest.org, you will see that the numbers are more like 60K in 0.5 seconds.
This page is a 2000 plus word article that includes an image, two web fonts plus some CSS and Javascript.
The rest of this page explores in more detail how to get under that 100K barrier.
Let's start with images
Images are compressed and delivered in optimal format for modern web browsers. For example, this image compresses from the original 1MB JPEG to a 20K AVIF.
While not perfect, it's perfectly acceptable for most viewers.
Whatever device is used by the visitor, the image will weigh as little as necessary while maintaining a reasonable quality. The ultimate goal of an equitable website building platform is to ensure its visitors download a minimum of resources in order to engage with the content.
Images are configured in such a way that the visitor's browser will select the best sized image for the dimensions and capabilities of their device.
Fonts
This website happens to use the Ojuju font for headings and the Piazzola font for text, both available at zero cost from Google Fonts.
Instead of downloading the complete fonts to the visitor's browser, the platform will only download those characters and styles actually used in the content - the difference can be over 200K less data.
This also means that websites built on this platform can use multiple web fonts to enhance their appearance.
Cascading Style Sheets
This site only sends the CSS rules actually needed to format the content.
For example, this page doesn't include cards. If it did then more CSS rules would have been downloaded. Same thing for image carousels.
The platform ensures that only those rules required for the content are downloaded for each page.
Javascript
About 10K of Javascript was downloaded to your device after the content was rendered. It captures details about your experience including how long it took to download, the page weight and other metrics like how long you were engaged on the page.
These are sent back to a database which the owner of the site can analyze in order to make informed decisions about improving accessibility of the content, for example.
This is over 100K less javascript compared to the ubiquitous Google tag manager.
Privacy
The "easy" way to use free web fonts and have site visitor metrics is to reference Google libraries in the page header. But as shown this hugely inflates the volume of data downloaded.
Not only that, it obliges every visitor to reveal their IP address and device details to a massive advertising company. Websites should respect their visitors' right to privacy by default and make no assumption that a tacit agreement has been made to the contrary.
By self-hosting web fonts and using its own analytics code, the platform assures the privacy of all of its visitors.
Javascript Modules
The focus of this article has so far been on the visitor, as it should always be.
However, the person that adds content to the site should expect the same performance as its regular visitors.
This website building platform allows owners to securely log in and directly change the content using an inline What You See Is What You Get editor. The content produced is pure, accessible HTML.
By contrast, most website building platforms require you to log in to an application in order to select themes, plugins and various elements which get bundled into massive javascript files and included in the published website along with the HTML.
This is the main reason why websites built on those platforms are so slow and heavy. They oblige their visitors to download lots of javascript forcing the visitor's device to do lots of processing work.
Javascript is not like images and fonts. After it's downloaded it has to be compiled and executed and it's this which makes websites slow for all visitors except perhaps those living in affluent areas who can afford expensive devices.
The inescapable truth is that most websites today are hugely iniquitous affording access only to those who can afford it.
Someone visiting one of these javascript heavy websites on a $200 android phone on a patchy connection in Africa or South America probably wouldn't even be able to connect let alone see the content. Meanwhile, visitors using the latest iPhone in California or London probably wouldn't notice.
The main difference between the platform that built this site and a typical Wordpress, Wix or Squarespace site is that all visitors can engage with this site regardless of location or how much they can afford.
This platform sends about 5K of javascript which is only used to measure and report back visitors' experience. None of that javascript has any other purpose.
This section was supposed to be about Javascript modules.
There's a lot of functionality required to edit and publish a website - you need code for the owner to select and download fonts from Google for example. You need code to automatically save changes in a database and upload images.
Inline editing needs code to insert tables, paragraphs, headings, lists, blockquotes, styling text, inserting horizontal lines to name just a few of the features available.
Website owners should never have to download all that code all of the time every time they want to change something. Javascript modules now enable complex web applications to be engineered in such a way that the owner only downloads the Javascript needed for the specific task at hand.
Take authentication for example. There's a javascript module for that which weighs about 2K, but unless the user needs to authenticate there's absolutely no need to download it.
This is quite contrary to how most websites are built. Javascript frameworks and bundlers for example basically deny web access to all but those living in affluent areas. If you're
There can be no just reason a modern website forces each and every one of its visitors to download megabytes of javascript in order to access the content. That's borderline crazy, hugely iniquitous and a massive loss of economic opportunity.
Security
There are two fundamental principles behind the design of this website building platform. Performance was one and hopefully you will have seen that for yourself.
The other is security. When you have a content editing application one login away from a world of internet users, you had better be sure that no one can hack in to the application and delete your website or worse unless you pay a ransom.
For this reason the platform uses digitally signed JSON web tokens instead of cookies and passwords.
When a website owner logs in they authenticate through their email which they will have secured themselves. The platform's database server sends them an email containing either a random 6-digit code or a link. Completing the authentication results in the issue of a pair of digitally signed tokens that are unique to the owner's email address and website identifier. These are then stored on the owner's browser.
The access token is included in every database request sent from the owner's browser and is validated by the server before executing the request. Access tokens are configured to expire after 5 minutes at which point the owner's refresh token is then used to automatically send a request to be issued with a new pair of tokens.
In this way the owner's exposure in case of theft is limited to 5 minutes. In this way also the owner can stay securely logged in for ever since there is no password to expire or cookie to manage. This system of automatically refreshed digitally signed access tokens is arguably the web industry's best security solution at present.
While similar solutions are commercially available at very high cost (see Stytch, for example), this website building platform includes it as standard because all website owners must be assured that their website content is secure at all times.
As it happens, it's not possible to steal the tokens online because the platform unconditionally publishes all sites with a strict Content Security Policy.
Content Security Policy
A strict Content Security Policy disables the most common forms of online attack like cross site scripting. The policy instructs the browser to only allow javascript to be executed if the javascript code's digital signature matches the signature declared in the policy.
You can see for yourself how this platform's security measures up at the Security Headers web site.
This platform guarantees the highest A+ security rating of every web page it builds. Website owners should expect this as standard and wary of any application that uses cookies since hackers exploit the inherent nature of cookies to lure unsuspecting users into cross site request forgeries.
Passwords are a similar anachronism, since they are forgotten and an all round inconvenience. Note also that many hacks are socially engineered and involve some form of breaching password security.
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:
- 100KB maximum data downloaded to first time visitors
- 90% of pages loading in less than 2 seconds
- data sent only when requested
- 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 hackers
- secure log in for owners and visitors
- separate editor and live websites
- inline feature-rich content editor
- choice of all available Google fonts
- independently publish editor and live websites
- content backed up every day
- download all current website assets at any time
All of these features are included in a single web builder application. Try downloading your website from Wix, for example.
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.