This site uses cookies to enhance your browsing experience and deliver personalized content. By continuing to use this site, you consent to our use of cookies.
COOKIE POLICY
Statically generated sites are becoming more popular on the modern web because they are very secure and offer fast page load times. They can be much quicker than server-side rendered applications or applications with dependencies on remote APIs (application programming interfaces) to load meaningful content into the view. While historically static sites have been difficult to manage, today, we have several tools like Gatsby, Next.js, and Nuxt.js to help manage static content. Let’s explore how static site generators can take raw data and create a fully functioning website.
Data for statically generated sites can come from various sources. Most statically generated sites can consume Markdown, a specialized way to format a rich text. This type of content is great for authoring articles or sections of content on a website. Markdown also has full support for embedding images and hyperlinks.
Other common data sources include RESTful APIs, REST (Representational State Transfer) like APIs, and GraphQL. All of these scenarios involve serving up application data using HTTP/HTTPS requests. You may be thinking, “How can a static site use an API? I thought you said earlier using an API might be slow.“ Static sites pull that data before the users see it, so they do not have to wait, unlike traditional applications consuming APIs.
Data can come in almost any format. But how do we translate that data into a static site? Each static site generator comes with a way to build or re–use modules with consumed data. For example, in Gatsby, this is a source plugin (Nuxt, Next, etc.). These source plugins digest the content and provide it to the static site generators to be consumed later. This process informs the site of what content is available. So, where do we put this data from the source plugins? One word – templates.
Static site generators can define many types of templates. This is generally where a lot of the custom display code makes your website look the way it is supposed to. Templates are skeleton display codes with placeholders for custom data to be inserted (page header, navigation, etc.). It‘s like having a generic form ready to be filled in with custom data.
These source plugins supply the data, and we have these templates, but how do we get a webpage on someone’s screen? That is where the build step comes in and where things can get tricky. Static site generators have a method of injecting the raw data collected by the source plugins into your templates and outputting raw HTML. This is known as the build process. You may be thinking, “What‘s the catch?“ Building can be expensive. Build times vary based on how much content you have on your website. If you have thousands of records to be processed, this can take some time. Fortunately, static site generators are starting to mitigate this time cost and allow you to build the site incrementally. This allows you to rebuild only the sections of the site that have changed.
There is certainly a trade–off, but you will save your customer the time it takes for a server-side application to render the page. It may take longer to make the initial changes to your site, but you will save on every page load when the user is looking at the site providing your customer with a better experience.
Once a site is built, all the artifacts can be published to allow users to interact with the content. The statically generated site can be published to a content delivery network (CDN) like Netlify, Surge.sh, or GitHub for virtually no cost and incredibly fast response times. CDNs are usually set up with distributed data centers, so your website will scale well across the world. This is a huge win since you will not have to stand up expensive application servers in Azure or Amazon Web Services to host your app.