It all started when we (Oberon) noticed a certain pattern among a subset of our clients — festivals. Their sites tend to have lots of issues with server load and costs.
They are, after all websites that remain largely unused for most of the year — until they’re not. And at those few yearly moments (such as at the start of a ticket sale), server loads can get really, really high.
This makes most festival websites not particularly good candidates for hosting on servers that are shared by multiple sites, because they can bring down all other sites during this brief period. Additionally, clients are paying a fixed hosting fee for a server that mostly remains unused throughout the year.
In the past we’ve ‘resolved’ these issues by adding an additional caching layer like Squid, CloudFront, etc. Adding these kinds of extra layers does make you think about why these sites are built as dynamic applications anyway.
For example, festival programme items rarely change after their initial publication, and it’s not like most of the content on these type of sites is particularly ‘realtime’ anyway.
What if we could just keep the entire site static, only updating it if changes were made in one of the data sources? We could then put it on a pay-per-request static file hosting service (like AWS S3), where we can basically scale to infinity if need be, while keeping the costs low during the down periods.
When our company was approached by a new client (that had sadly earned a reputation for its website failing during peak hours), it felt like the stars were aligned, and we decided to go full JAMStack.