How Webpages are Assembled
In this article we review how Zesty.io uses all of the content, files, and settings for a web property to generate the HTML, CSS and JavaScript for a webpage.
(If you know all this, jump down to the next section.)
Generally speaking, a webpage is a document served over the internet made up of HTML, CSS, and JavaScript. When you enter a URL into a browser, the computer powering that URL responds with the correct webpage document, and the browser interprets all that code. Once the code has been interpreted the browser renders your web browsing experience - all you can see, hear, click, hover, tap, swipe, etc.
A webpage is made up of two main sections: a head and a body. The head is all the invisible information that the browser and other internet services need to know about the page. For example, the head is where you put the information you want a search engine to show when your page comes up as a result, or what image and copy you want social networks to show when someone shares a link to this page. The head also can contain references to files (e.g. style sheets or JavaScript) the browser needs to correctly render the page. The body is all the content and structure you can see in the browser including the header and footer, the big hero image, the page content, the social icons, and more.
How Zesty.io renders a page can be unclear by simply looking at the interface. So, how does Zesty.io take the content, code, and settings from all over the interface and compile that into a document for the browser? We'll break everything into its parts and look at example code to determine where each piece comes from.
When a valid request is made to a domain hosted by Zesty.io first we check to see if it matches the settings for that domain. Does
http need to redirect to https? Does the root domain need to redirect to www.? Then we check the path. Does /blog/example-article/ have an entry in this Zesty.io account or does it redirect to /news/example-article/, or is it a 404? Once we arrive at the correct path and it is a real page on that Zesty.io site, the webpage begins compiling.Zesty.io takes all of the editable style sheets including LESS, SCSS, and raw CSS, runs them through a compiler if necessary, minifies them and provides the browser with a single, clean
site.css file. It does the same thing with editable Javascript files for a site.js file.The head is built based on the meta information of the page and the site-wide settings.
Here is a simplified
<head> element featuring dynamic elements called out with content in curly brackets and where to edit in parentheses:<head>
<title>{Page Meta Title}(page settings) | {Site Title}(content clippings, can be removed in Site Settings)</title>
<meta {default settings}(cannot be edited)>
<meta {favicon and apple touch icon meta}(Doctype/Favicon/Metatags)>
<meta name="description" content="{Page Meta Description}(page settings)" >
<meta {custom meta tags}(Doctype/Favicon/Metatags)>
<meta {social share meta}(page settings)>
<link {linked css files}(Editor)>
<link href="/site.css?v={version number}(autogenerated)" >
<script {linked javascript files}(Editor)></script>
<script href="/site.js?v={version number}(autogenerated, can be removed in Site Settings)" ></script>
</head>
<body>....
When Zesty.io renders a webpage, within the
<body> tag, it references the loader file. The two exceptions are Ajax URLs and 404 pages; they are loaded directly, as is. Within the Loader file there is a {{ current_view }} Parsley call. The current_view call, dynamically references the specific template for the webpage that's being rendered. For example, loading the homepage would use the homepage template file where the loader calls current_view. This allows for site-wide template features to be used, like a header, footer and using site-wide scripts like tracking pixels.Here is an example loader file:
{{ include header }}
{{current_view}}
{{ include footer }}
<script src="sitewidewidget.com/plugin.js"></script>
This is also where all the Parsley calls are replaced with the content they reference from the database. For example:
<h1>{{ page.title }}</h1>
<ul>
{{ each list_of_colors as color }}
<li>{{ color.name }}</li>
{{ end-each }}
</ul>
becomes:
<h1>Hello World</h1>
<ul>
<li>Blue</li>
<li>Yellow</li>
<li>Red</li>
</ul>
Now that each of the individual pieces have been created and dynamic elements have been composed, the document is packaged and served to the browser.
For Zesty.io websites with full caching enabled, this whole process does not happen every time your site is visited. It happens once, and is provided to our global content delivery network (CDN) as a static file, and isn't compiled again until there is an a publish event on the instance or 24 hours pass from when it was first cached.
Last modified 4yr ago