I’m working on a large redesign for Synagro — the largest recycler of biosolid and organic materials in America. We’re talking sh*t here people, but it’s important work and somebody has to do it. I was going to write a comprehensive blog post after the site launches, but selfishly I’ll get more value documenting the process as I go along, so I can reference back to techniques that I’ve learned during development.
Site Optimization
I’m using the WordPress content management system and the Divi theme by Elegant Themes. Part of the challenge was reducing the bloat of Divi in order to create a performant site that will improve their search engine ranking.
I decided to use system fonts for the site typography. There’s no overhead to use system fonts and they look beautiful on their respective native environments. So, I didn’t need all of the Google fonts that Divi loads by default. To remove the Google fonts, I added the following in my child theme’s functions.php file:
| function syn_dequeue_styles() { | |
| wp_dequeue_style( 'divi-fonts' ); | |
| wp_deregister_style( 'divi-fonts' ); | |
| } |
Removing the Google fonts reduced the page load speed by half a second — that’s a lot of time!
Custom Plugins
Divi has a great admin interface for building pages. They have a lot of default modules — accordions, galleries, calls to action, etc. — a flexible grid structure, and decent access control. The modules are glorified shortcodes — the standard implementation for these kinds of large frameworks (see Visual Composer). They also provide a way for developers to override default modules and create new modules entirely.
For an override or new module, I created plugins to keep the code separate from the theme. One WordPress function that I used in the plugins, and one that I feel deserves more attention, is wp_localize_script. Originally designed to allow language translations, it provides an easy way to pass PHP values to Javascript. It’s worth reading through the documentation, but here was my use case:
PHP:
| function syn_explore_assets() { | |
| wp_enqueue_script( 'explore', plugins_url( '/js/explore.js', __FILE__ ), array( 'jquery' ), PLUGIN_VERSION, true ); | |
| wp_localize_script( 'explore', 'explorePlugin', array( 'oImage' => plugins_url( '/images/o.png', __FILE__ ) ) ); | |
| } | |
| add_action( 'wp_enqueue_scripts', 'syn_explore_assets' ); |
Using wp_localize_script, I can now get the full path to o.png to use as an image source in my Javascript.
Javascript:
| var imageSource = explorePlugin.oImage; | |
| $(element).html('<img src="' + imageSource + '" />'); |
Accessibility
In an effort to make the web content more accessible, I used the WAVE web accessibility evaluation tool. I had a few outright errors and several alerts, all of which could be solved by the same technique. The errors were caused by empty <button> elements used for the header search form and for the close button within the mobile menu. The alerts were largely caused by “Read more” links in which the WAVE tool reported the following:
“Link text contains extraneous text or may not make sense out of context.”
More explanation from the tool:
“Links, which are often read out of context, should clearly describe the destination or function of the link. Ambiguous text, text that does not make sense out of context, and extraneous text (such as “click here”) can cause confusion and should be avoided.”
Makes sense. For both the empty <button>s and “Read more” text, I wrapped descriptive text in a span, classed with “wai-hidden”.
The stylesheet declaration for “wai-hidden” follows:
| .wai-hidden{ | |
| position: absolute; | |
| left: -10000px; | |
| top: auto; | |
| width: 1px; | |
| height: 1px; | |
| overflow: hidden; | |
| } |
This way, the button text and more descriptive “Read more” text does not affect the visual appearance of the page, but makes the content more accessible.