I wanted to put V3 to the test and dogfood the product a big while launching V3. So, I thought it was about time to update the WP Rig theme on wprig.io. This was a great idea as it highlighted some shortcomings of WP Rig as well as helped to catch some bugs that still lingered from the V3 rewrite. Below is what I learned.
Making new components is too manual
I have been using WP Rig for a few years now on a handful of projects, yet, even while working on this new theme, I still made some mistakes while making the new Fonts component. This lead me to realize that the process of making new components is too prone to human error.
In an upcoming new version, I would love to add a CLI script that automates the process of creating new components getting them all hooked up to the theme. Essentially scaffolding them for the developer while also maybe asking for some input to streamline the customization of them.
Localized Google Fonts
Currently, we have a component for fonts, and a pretty simple way to add new ones to your theme – if you are ok with your theme constantly pinging the Google Fonts CDN with requests to get the fonts. This is not ideal for performance for a number of reasons.
I think WP Rig should have a built-in dev system that gets the fonts locally from Google and bundles them into the theme itself so the theme is requesting them from the same server its deployed to. This would:
- reduce reliance on the Google servers to serve your website.
- make requesting the fonts much faster and more secure.
- eliminate fonts as a possible blocking resource within the theme.
- improve lighthouse scores for the theme.
Improve performance of Styles and Scripts components
The are already fairly performant, however, the global scripts still get flagged by Lighthouse as render-blocking. How do we eliminate this issue and ensure no WP Rig styles/scripts are EVER a source of Lighthouse issues? We could provide some options here.
- Offer the ability to easily inline specific scripts so they don’t need to be requested via HTTP. This would mostly apply to globals or styles that are crucial to above-the-fold elements (especially persistent ones). We must be cautious here though as there are negatives to over-relying on this approach.
- Adopt an npm tool like “critical” to make it easier for theme devs to determine which styles need to be inlined or otherwise more highly prioritized.
- Explore other WP-based tools that might help with more dynamically determining critical styles or scripts that we might be able to build an integration with.
Block Styles Component
We should make it easier for theme devs to create block styles from directly in the theme code-base. While I still believe that custom blocks are still a better fit for plugins, themes should offer block style opinions and capabilities.
What went well
- Going to a dark theme from a light theme was super easy.
- The navigation was fairly straight forward to customize, although I didn’t try to get too fancy and basically just stuck with the stock nav for the most part.
- Adding random CSS tricks from Codepen could not have been easier (Tools cards with hover effect).
- I spent a total of about 4-5 hours on the new version of the theme.