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
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.phpin 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
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.
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.
Funny you should mention this. I just picked up a prospective maintenance client who’s site builders took it a step further and hard-coded all the main page templates too. You open up, say, “Home,” or “About” or “Administrative Hearing Procedures” and the Edit box is… 100% empty. If you want to edit a page you “simply” open a code editor (or, I suppose, Appearance->Edit Theme), find the corresponding page template, and hard-code the necessary HTML. Then just fire up CodeKit or some other tool (because of course all “programmeraggers” use SASS), dig around till you figure out how they structured their partials libraries, and Bob’s your uncle!
I mean don’t get me wrong, if I take them on it would be more money for me. And if I wanted to be a total jerk I could keep them over a barrel. But I’ll probably recommend they let me at least rebuild their pages so they can make simple changes in the future.
Note: the last thing their old developers did before they dropped out of sight was add a big COVID notification on their homepage. Hardcoded in HTML and SASS, of course!
But aside from costing maybe $100 per edit their site sure loads maybe 10% faster without caching. 😂
Joking aside it’s definitely the case that overriding theme components with plugins of any kind tend to cause slowdowns.
And joking aside I also get that most people (including far too many “professional site builders”) start out with a bloated kitchen-sink theme, loads it up with even more bloatware plugins, pastes in cookie-cutter rows and columns from theme or page-builder or Gutenberg block “libraries,” doesn’t know how to optimize images… or else they hire a “programmagger” who hard-codes it tighter than a Wall Street real-estate contract.
I don’t do either of those things so I enjoy cleaning them up or rebuilding them.
Excessively hard-coding your theme to the point that it’s no longer a CMS…is stupid.
Could you please make a video about the process? I’m sure it will be useful.
Not possible. Either it’s 3 hours long and very boring, or 10 mins long and doesn’t actually show you how to do anything. Even if you saw the 3-hr version, you wouldn’t understand what I’m doing or be able to apply to every situation as I would code differently depending on client needs.
Just curious what do you take for hardcoding a Header / Footer for a client?
Thank you for the interesting reads. 🙂
Usually around $800-1000, but I’m so busy lately that I’ll probably never be available for this again.
Thanks johnny! i understand verything – i just needed a little hint where to start.
When updating your theme or the elementor page builder, I am guessing this would reset your custom code and you would have to manually put everything back after each update. Or you would have to do a manual update that omits anything that impacts the header and footer, which would be kind of tedious. Is that right?
This is why you should always use a child theme.
Thank you, that is very helpful! If I actually achieve all of this on my own I will be a very accomplished person.