HARDCODING your (pagebuilder) header and footer

Some pro tips when manually-coding your bloated custom pagebuilder header and footer.

This post was inspired by the work I did last night for a client site. He was sick of his pagebuilder slowing down his site speed and wanted to move away from it.

The very first obvious step for me was getting rid of the Elementor custom themebuilder function used to override his theme header & footer. Once that’s gone, the pagebuilder and theme are truly decoupled and you’re free to switch out the theme first or pagebuilder first (your choice).

For those who don’t know, pagebuidlers generally cause 4 main bloat issues:

• Messy ugly waste of HTML code – literally 10-30 times more code than it had to be. (Often referenced in page scores as “excessive DOM elements”.)
• Ugly waste of CSS code – not only so much more CSS, but also lots of styles overriding each other everywhere.
• Slower dynamic PHP processing – of course!
• Higher memory use – slowing down your server.

Let’s go over what I did briefly and hopefully inspire others to take on the task.

STEP #1 – make a staging site and new theme

Because duh. You need to work off another site so you can compare visuals and styles side-by-side.

• Save backup of the theme before you touched it.
• Rename the version you’re working on to a new name. (This is done by renaming the theme directory, and also changing the “Theme Name” in style.css.)

STEP #2 – recode the template file

I suggest doing the footer because it’s usually easier.

Items are laid out in uniform spacing, no dropdowns or off-canvas mobile menu JS animation, the code is easier to read.

• Usually the footer template file is something like footer.php in your theme directory.
• Different themes may have different file name or place it in a different directory.
• Developer themes (like Genesis) customize using hooks & filters in functions.php. Which is easier in the amount of work involved but harder for non-coders to visually understand things.

Add the divs, then inside you place raw html or register widget areas.

• For most things, you only need about 3-levels deep of nested divs. One for the section (class=”footer”) to set background. Another for the wrapper (class=”footer-wrapper”) to control content width. And last one for the footer content styling (class=”footer-widgets”).
• After you put the divs and with sensible div classes, put your content in hard HTML or make the widget function call.

STEP #3 – register new widget areas (if needed)

There are 2 ways to register new widget areas from functions.php depending on your theme.

• Put in the code snippet for it, which may vary depending on if you already have other widget areas already registered. Read this guide or this guide. (I can make my own if you guys can’t understand.)
• Or put in hooks and filters if you’re using more developer-friendly themes like Genesis.
• Please…do not install those plugins for adding widget areas. You don’t need that!

STEP #4 – add content (if needed)

• Go add content to those widget areas.
• Those who hardcoded the content can skip this.

STEP #5 – style your template area

Add CSS styles to your theme style.css.

So you added the template code and put some content in. Now you’re at the last part which is the styling. Those that are handy with CSS don’t need much explanation here.

For everybody else, open up your live and staging site side-by-side and start plugging in CSS.

• Work either from desktop-first or mobile-first then do media query overrides after.
• Going “desktop first” mentality will probably be easier for first-timers whereas the opposite is more true for seasoned designers.
• I highly recommend writing your CSS from scratch rather than copying your pagebuilder’s ugly math calculations.

Copy new theme over to live site.

• Copy the new theme directory over to the live site.
• Don’t forget to copy over any additional CSS you had in the Customizer.
• Activate new theme on live site.

DONE!

Enjoy your work. Hardcoding the theme and footer literally makes it 10 times less HTML output, 10 times lighter CSS styling, and much lighter dynamic PHP processing. It likely chop outs any unnecessary bloated JS/CSS library requests as well. From here on, you’re that much closer to reducing your pagebuilder reliance and can slowly convert your pages one-by-one to a much faster Gutenberg.

I don’t know how many of my readers can actually follow this guide but I reckon even if you can only do 1-2 of the steps and hire a dev for the rest, the effort is still so worthwhile! At the very least, granular steps like this will push you to grow as a professional.