Pre-rendering HTML content, key to generating all types of content

▶

I want to tell you about something I find very interesting, which I also think was a very good idea I came up with, and which has been very useful to me. Actually, for two reasons. I call this "content pre-rendering," a perhaps somewhat grandiose name, but I'll briefly explain what I mean by it.

It's a concept I've talked about before. Remember that in other videos, I've shown you how to generate a PDF and how to optimize a blog. I even published a playlist showing you how I took my blog's score from 33 to 100 on Google Speed ​​Test—or somewhere around there, as you know, that test is a bit tricky. For me, the key to that improvement was precisely this: content pre-rendering.

What exactly is it and how does it work?

It all starts with my Content Editor, where I store the base content. It can be a post or, as in this case, an excerpt from a book, i.e., a chapter.

I already have some things highlighted: code, paragraphs, headings (H1, H2, etc.). But even if we have structure, we often make additional changes—especially in the case of a blog—to code blocks. For example, it's common to apply a syntax highlighting plugin.

However, what you see in this snippet is just a <pre> tag with <code>. There's no visual highlighting. If you remember the video on PDF generation, I showed you how Highlight.js adds <span> tags, classes, and colors.

Highlight.js only runs on the client side, that is, when the user accesses the browser. For me, that was a problem:

• On the blog, I wanted to remove that Highlight.js plugin to improve SEO (although it wasn't very heavy).
• In the books, I wanted the output to be already highlighted, regardless of the browser.

If you've read any of my books, you'll already know that the code appears in gray blocks without highlighting because it hadn't processed anything. That's exactly what I wanted to change.

Pre-rendering implementation

I've already shown you a bit about it: I have a button or link that allows me to generate pre-rendered content, and from there, using JS, I save the HTML blocks defined with IDs that I want to save. I also perform pre-processing to remove, add attributes, or any other structure I want, and reformat to comply with standards like XHTML 5.

There are packages in Node that allow you to do this: they execute the JavaScript, extract the HTML, and save it. I didn't use any; I preferred to do it manually within an editable view, which gives me greater flexibility. That way, if I want to change something manually later, I can do so.

Advantages of the manual approach

It allows me to:

• Visually review and correct content.
• Enable or disable things like indexes or highlighting.
• Inject custom classes into the generated HTML.
• I do all of this on a page that contains HTML, styling classes, and a fair amount of JavaScript. From there, I can control what happens before saving the final result.

System Structure

We always work with two fields:

• content: This is the editable content, what you write or import.
• content_render: This is the rendered content, the final result saved after the pre-render process.

This allows me to keep both: the editable original and the optimized content for display or PDF generation.

What can I do with the result?

Many things! Two clear examples:

1. Display an already processed blog post, without having to highlight it in the client.
2. Generate books with already optimized code blocks.

I love this approach because it gives me full control over the final content, without depending on external libraries and in real time.