At one point, online store websites rely heavily on dynamic websites. But due to the need for websites’ to work seamlessly with various devices, static websites are now making a comeback and are better than ever.
When comparing static vs dynamic website generators, you'll easily see that static sites generators and static website hosting platforms allow Github integration, global CDN, SSL certificates, and free custom domains. Hosting providers such as Netlify go up the notch and even deal with redirects such as 404 errors, proxies, and even password protection.
With all these advantages and with their drawbacks minimized, static site generators are here to stay for the long term. Other technologies such as the JAMstack also supplement the strength of a static site generator. With that said, what are static websites exactly? Why are they part of many offerings under web-design-as-a-service packages these days?
There's been much talk recently about STATIC SITES and the new generation of tools used to create them, commonly referred to as "static site generators" or "static site engines." There is also a lot of debate about dynamic vs static site generation. What makes a static site generator better and why switch from having a dynamic website to a static website?
As with any new technology, it can sometimes be hard to differentiate the hype from reality. The term "static site" is an interesting one if you think about it, as it defines itself by what it lacks. The "static" aspect doesn't describe a feature as the absence of one: dynamic page rendering. Once upon a time, probably before we commonly used the term "static site," this would have been considered a weakness.
Those of us who've been working in web development for some time probably recall building static sites using tools like Dreamweaver, HomeSite, or (heaven forbid) FrontPage. These pages' content could only be changed by manually altering the existing site files and replacing the files on the server via FTP.
There were several issues with this process. Adding content to the site required a moderately high level of technical knowledge, either knowledge of the specific tool used to design and build the site or of HTML to hand-code the site. One also needed to understand how to deploy the site to a host via FTP, which isn't necessarily straightforward for non-technical users. This meant that the content creators, who are frequently non-technical, could not directly or easily contribute to the site and required a web developer's assistance to add new content.
It was creating new pages that typically required copying and tweaking existing pages. As the site grew, maintaining proper navigation and links naturally became both tedious and too error-prone. Some tools offered features like templates that tried to solve these issues, but these could be complicated or cumbersome to create.
In addition to these issues, there was the limitation that if your site required dynamic features like comments or forums, for example, this was not possible in a purely static website.
Dynamic sites seemed to fix these issues. Non-technical content creators could create and update pages via backend forms without understanding the specifics of website development tools or HTML. For most dynamic website supporters, this is one of the best things about it.
Since the content and pages were all driven from a database, navigation could be generated automatically. Also, by definition, dynamic sites allow for dynamic features such as forums or comments.
In the case of content-focused web pages, dynamic sites often took the form of a content management system (CMS). These could be custom-built to the site's needs or, very frequently, selected from several commercial or open-source options.
To this day, most of the content published on the Web runs through some form of a content management system. Popular open-source options include WordPress, Drupal, Joomla, and Concrete5, to name a few.
Nowadays, these systems typically handle much more than merely content creation and publication, with features such as complex roles and access control, workflow management, document management, and syndication.
These additional features lead to the biggest issue with dynamic sites: the solution is often more complex than the problem. Under its need to cater to a broad set of customers, a pre-built CMS usually has a steep learning curve for developers and content creators. Meanwhile, a custom CMS requires extensive development efforts and access to a developer should issue or necessary changes arise.
Hosting dynamic sites is complicated by the need for database storage (and backups) and support for whatever dynamic language the site is built upon (PHP, Ruby, etc.). Factor in the need for regular updates to the dynamic language, database solution, and even the CMS software itself, and it becomes rather evident that, while dynamic sites solve many difficult problems, they bring their own set of complications.
The complexity of content management systems was not well suited for smaller, content-focused sites or blogs that didn't require advanced features like complex user roles or workflow. Blogging engines, the most popular being Wordpress, aimed to solve this by making development simple, with pre-built and easily customizable templates, and publishing content quickly and easily.
Blog engines don't negate the need for supporting a dynamic language(PHPin the case of WordPress) or for a database(typically MySQL for WordPress). However, WordPress became popular enough that many hosts made "out-of-the-box" hosting solutions that simplified set up and maintenance.
Nonetheless, over time, WordPress has begun to gain some of the complexity of a typical CMS, and it is generally lumped in the category of CMS by most industry research. Many sites heavily depend on features added via plugins, the quantity and quality of which can dramatically impact site performance. Also, features like plugins and "shortcodes" can affect the portability of content, keeping your site tied to the WordPress platform.
Some in the blogging community felt that WordPress and competing for blog engines like MoveableTypehad strayed so far from the simplicity of their initial blogging focus that they created new projects, like Ghost, that aimed to get back to the basics of just blogging. Ghost's tagline is, in fact, "Justa blogging platform."
Whatever dynamic complexity sites may bring, there is simply no avoiding the need for dynamic data for most client-side use cases. So it wasn't until the rise of new services that can fill these voids that websites that are static became a viable option of more than just "brochureware."
There are numerous services, both free and paid, that offer the ability to add dynamic aspects into static pages (it's important to note that these services are not specifically intended for use only on static sites). Some popular options include:
There are many more covering a full range of typical site requirements. Even BaaS (back-end as a service) solutions like Parseor, Kinveyth, offer APIs that allow developers to pull any form of arbitrary dynamic data into a static page.
So far, we've covered some background showing how the static web pages of old failed to meet the Web's needs as websites became more complex and interactive. We discussed how dynamic sites generally and content management systems specifically solved some of these problems and increased complexity in both development and authoring.
Blog engines partially addressed these issues but also took on some of the complexity over time. Finally, we saw how the rise of services has helped make static pages a viable option again.
This is probably the key defining characteristic of a static site and part of why static sites tend to perform so well: there is no server-side generation at runtime. For instance, this means that every visitor to your static site will be served an identical copy of index.html from the server until it is manually overwritten, say by uploading a new file or by committing to a Github repository.
There is no server-side language.
It follows from the preceding characteristic that there would be no server-side language (like Ruby or PHP, for example) involved.
There Is no database.
As there is no server-side language to speak to a database; therefore, there is no database. This does not mean that there is no data. There can be data stored as files or via an external service like the ones discussed earlier. This means that if you need standard features like user registration/login, this would need to be via an external service.
Static sites are HTML, CSS, and JavaScript.
This seems fairly obvious, but it should be clear that since static sites are intended to run in the browser, they must rely on web technologies to function. Of course, this can also include images like JPEG and GIF, graphic files like SVG and WebGL, or data formats like JSON or XML.
While each of the preceding features brings with it certain limitations, they also lead to some of the primary benefits of static sites:
As there's no intermediary, i.e., the database involved, the threat of code injection is minimal for a static website. No plugins and dynamic software to host the website.
Static websites are a safe bet compared to dynamic ones when it comes to security as they don't rely on CMS plugins. APIs and JavaScript are used to handle static websites' dynamic functions, eliminating the risk of getting hacked. On the other hand, active websites are highly prone to get hacked due to multiple content sources and plugins.
A report by WP WhiteSecurity states that about 70% of WordPress sites are at risk of getting hacked by malicious hackers because of lack of maintenance and upgrading. Ugh, scary.
You must have occasionally come across an error message saying, "The connection could not be established.' This primarily occurs because of database errors. Serving just essential HTML files makes it easier to host them anywhere with ease, like on a CDN.
Hence, whenever there'd be an attack on the server, the static website is redirected to another closest node, unlike its dynamic alternative where the website might go down for a few hours.
The absence of a middleman/database makes the static site much more speedy and easy to load. A static site is ten times faster than a dynamic site that is built with a CMS. Another reason for a static website to run faster is that it can be served from the node closest to the browser.
According to research by Kissmetrics, about 47% of people expect the website to load within 2 seconds, and a whopping 40% of people will not wait for the website to load for longer than 3 seconds. Hence, getting a static website also helps in getting more traffic by reducing the abandonment rate caused due to slow loading.
Static websites have basic HTML files, which require less space making the hosting of these websites cheaper than that of dynamic websites. Organizations with static websites save up on the costs and channel those resources to integrate Git or automated builds to incorporate the system's latest changes.
What to do when your website is finally up and running? Handling massive traffic on a dynamic website might be cumbersome, as it requires complex code playing on the server. Basic static websites with HTML files can be easily scaled up by just increasing the bandwidth.
When online store websites would have to rely on dynamic websites for their organization and integrate those complex coding and deal with tedious scripting, there was a time when online store websites would have to rely on dynamic websites.
With tools like Magento, it is possible to have a static website for shop-centric businesses. A Java-script based shopping cart, called Snipcart, integrates an e-commerce site's functionalities to a static website, eliminating dynamic websites' need. Snipcart dashboard can manage sales and product inventories, and its API can be integrated with shipping service providers and inventory management software systems.
With all these benefits it is not hard to see just how advantageous static websites are to any business.
At WebriQ, we highly believe in the potential of static website builders and Headless CMS, particularly JAMstack, when it comes to implementing websites, eCommerce carts, landing pages, and web apps.
As we have already analyzed many times before, moving away from a monolithic, legacy, centralized, or traditional approach is the right decision. To answer to the demands of our time, we need a decentralized system—whereby each software component is chosen to ensure the best fit for business needs.
What would you say if we told you that there's a new way to design and launch projects? A page builder called Webriq Studio, that is fully-fledged with endless customization possibilities. You have everything at your fingertips - from landing pages all the way up until eCommerce sites ready for launching!
Check out our newest JAMstack offering, the Webriq Studio Landing Page Builder and Microsite Builder, and see for yourself what it can do for you.
What can you expect from Webriq Studio? These are just a few of the good things you can look forward to:
Webriq Studio can deliver a fully-functional SaaS experience, giving you the opportunity to build pages backed by powerful technologies without having to waste time trying figure things out on your own.
Get ready to build your project with the power of Webriq Studio! This page builder is a one-stop shop for creatives looking to design and launch their websites.
For all your website building and hosting needs, we can take care of them for you at Webriq. Talk to us and see how we can help you.