As I get back into doing web development more and more these days, I’ve started to pay attention to some of the finer points, such as not having a sluggish site that turns off visitors. To that end, my Trello Board for this site had a card/story sitting in the “To Do” bucket for speeding up DaedTech’s load performance.
The first thing that I did was visit GTMetrix and run a baseline to see if subsequent things that I did would improve performance. From there, I installed W3 Total Cache which is a WordPress plugin that provides a whole bunch of functionality for speeding your site, mostly revolving around setting cache settings. After a bit of poking around and research, I figured out what was going on, and I enabled settings that helped with some low hanging fruit.
This included “minification” of CSS and javascript, a process whereby the whitespace is compressed out of these things as they’re sent from the server, thereby reducing the total amount of data sent (and thus time to process that data on the client side before displaying it). It also included optimizing the caching settings that the site suggests to returning visitors so that pages, styles, media, etc are stored locally on your machine as much as possible, which prevents reloads. This also setup the further use of GZip for further compression.
For improvement in the future, I installed a plugin called WP-Smush.it that will use the Yahoo utility for image compression to any file I add through the media library. This seems convenient enough that I should probably start adding files through the media library in general rather than simply putting them on the server and linking to them at their full local URL to get this functionality.
While I’m at making resolutions to improve speed going forward, here are some other tips that I’ve picked up today:
Serve scaled content. Meaning don’t put up some huge image that the browser downloads only to use CSS or HTML in to tell the client to shrink it down. Send over the smallest possible image.
Favor using my own images instead of embedding them from other sites. This lets me control the cache expiration suggested to the browser and the size as well. With hyperlinked images, I don’t have this control.
Specify the image dimensions rather than simply accepting the default.
Consider using image “spriting” to combine images such as the gaggle of social buttons into a single “image” to reduce the amount of stuff getting sent over the wire.
Consider using a content delivery network to store your resources in places closer to site readers.
Try to limit the number of things that make HTTP requests (like social media buttons)
Use a utility to defer javascript execution so that it doesn’t block page load
I’m no web performance guru by any stretch. This is just what I pieced together in a morning after saying “I want my site to load faster”. I’m hoping that people in a similar situation to me will see this and realize that there is some pretty low hanging fruit to be picked here and that it isn’t terribly complicated to do so.
I discovered today that image resizing wasn’t working for the blog. Amazingly, I’d never had an occasion where I cared about resizing an image until just now. But, when I did, I discovered a frustrating thing. In the “what you see is what you get” (WYSIWYG) editor for WordPress, the images were appearing correctly and looking good according to my sizing. But in preview mode, they were rendering at their original size.
After a bit of poking around, I discovered that my style.css was defaulting image height and width to auto. I removed this (under #content img), and everything was as I would expect. This seems obvious if you’re just talking about the CSS of some page, but I didn’t think of it off the bat, since the theme’s handling of this seems to run completely counter to wordpress.
In a bit of a reversal, I’m going to cut right to the chase and post my solution, followed by the back-story for those interested. I’m posting it right at the top because this would have saved me an hour or so had I stumbled across it last night, and I’m hoping it helps someone else later. So, without further to-do (points to anyone who can name the movie reference), here’s how to create a placeholder menu item in WordPress, without using the control panel’s menus (i.e. just the default menuing used by your theme).
The basic idea is that I wanted a menu at the top that had sub-menus, but without the menu item itself being clickable. The default in my theme (as well as twentyten and twentyeleven) is to have pages with no parent as menu-items and pages assigned a parent as sub-menu items. This is perfect, except for the fact that every menu item is a page, meaning that adding a page as the placeholder menu item forces me to add a navigable, empty page, which is kind of low rent from a design/UX perspective.
Here’s my solution to the problem. I created a file called “gohome.php” and added it to my theme folder. The file’s contents are simply:
Now, with this added, when I create or edit a page from the built in wordpress menu, I see the following options for template:
So, the interesting thing here is that wordpress picks up a page theme from a file by parsing its content for the commented line. I pieced this together from some blog and forum posts that I read (described in more detail below) and learned only through trial and error/deduction that WordPress picks up the fact that this is a page theme from the comment containing “Template Name” and the display name.
All this actually does is redirect the user to the home page if he or she happens to click on the menu item. It is perhaps not the most elegant possible solution (I would say that it would be more elegant to have the link not clickable in the first place), but it’s better than directing people to an empty, useless page and I like it better than another solution I found which was redirecting them to the first child. If clicking the menu item was a miss-click when going for first child this makes sense, but if not, I think this would be confusing.
Another alternative that I put into place was goback.php:
This uses javascript to effectively redirect the user to the last page he or she was on, instead of home. The “php code” here feels kind of weird, since the PHP serves only to house the necessary comment, but it works. I have both page themes in my arsenal now so that I can adopt whatever implementation I see fit. I’m leaning toward the “Go Back” theme since that seems a little closer to the actual desired effect – I’d rather the user click result in nothing than the user click result in going home (which will be jarring if not initiated from home page) or, worse, going to an empty page.
This is ultimately a hack. After all, I’m still actually creating a wordpress page and all that goes with it just to get the menu item. However, the page is empty and it does nothing but route the user elsewhere. This is the magic behind the hack.
So, use in good health – I hope someone finds this helpful. It’s not the most elegant solution in the world, but it’s one that clearly works within the confines of WordPress and doesn’t require modification beyond adding things to the theme. I prefer adding to the theme rather than modifying it, and I prefer either of those to modifying WordPress source, and this requires only adding to the theme. Furthermore, it doesn’t require using the WordPress menu structure, the motivation for which I’ll cover below.
My Quest For Sanity
Up until recently, I’ve had no need for a menu item place holder, as the only menu/sub-menu situation I had was one where clicking on the main menu item made sense. However, I’m in the process of prototyping a new menu layout for daedtech locally and the need to have a simple place holder came up. So, the first thing I did was follow the built-in menu-by-page paradigm, and that left me with the empty page. I looked in the wordpress control panel for a way to make the page non-navigable but this functionality is (understandably) not supported. I then tried making the page private, but I tried this half-heartedly, figuring it wouldn’t work. It didn’t.
So, I alighted to google to see what I could find. The first thing of note I found was in a lot of places, such as here, here, and here. WordPress has a built-in, customizable menu functionality. Great – problem solved!
Not So Fast
I could see how most people had solved this problem, and I followed suit. I diligently created a menu from the control panel using the pages that had previously been auto-menued by the theme. This took a while, and the API was intuitive if a little slow and cumbersome, but I finally had my menu structure in place. I saved it and viewed it on the actual site and saw that I had made a few mistakes. So, I went back in and modified a couple of things and saved again… only to get an error 500. I reloaded the page and tried again. 500. I closed my browser and tried again. 500. I restarted apache and tried again. 500. I tried other browsers. Yup, you guessed it… 500. Apparently, the menu structure save operation was passing too many post variables or some such thing.
Alright, time to take a break. I went and got some water and then decided to go back to google again. I read a few pages like this one and saw that the WordPress menu feature works great until you have about 24 menu items. Then glitchiness starts. As you increase it, the glitchiness becomes more apparent until, at 70 or so, there is nothing but glitchiness. I was closer to 24 than 70, but this apparent complete lack of scalability did not bode well for my future plans.
The general consensus in defenders of what was going on seemed to be “why would you want more than 20 menu items?” I view this kind of response as a non-starter and, in fact, a conversation ender, so I decided that if this was the prevailing attitude, I’d chalk the menu system up as worthless and seek another solution. I have to say that (1) I use WordPress and for free (2) the people from WordPress that I saw commenting on it did explain that this was an ongoing technical challenge that they plan to address in future releases. So, I’m not complaining at all – just a dispassionate assessment of the situation.
Back to the Drawing Board
At this point, I figured I’d exhausted my options for using the WordPress GUI and I started looking at plugins. These are so numerous and searching for them can be sort of exhausting, so I gave up on that. After a fruitless half hour or so of poking around, I stumbled on this blog post, by Bruce Header. He had borrowed a solution from here and linked to it.
Now, I was really onto something! This wasn’t really the behavior that I wanted, but it gave me two important pieces of information: this is how the page templates get incorporated and it’s possible to use your themed page to do a redirect. So, from there, I mustered my own solution of redirecting to home out of my limited knowledge of the WordPress codebase. Then, I created the place holder page as an empty page and set it to this new “Go Home” theme. I was finally in business.
Tweaking
After I got this setup, I realized while using it that the redirect to home was great if you started at home, but seemed a little weird if you hadn’t started at home. So, I debated how I’d want to handle this and concluded that a conceptual refresh (i.e. redirecting to the previous page) would be best, or at least desirable enough that I ought to include a template for that as well. From there, the javascript was really trivial. So, leaving the page empty and using the “Go Back” template creates a situation where the user navigates from X to Y, and Y simply deposits them right back at X. Short of eliminating all clickability, this is probably the best solution.
In the interest of non-clickability, this is the most promising thing I’ve found so far. However, it appears only to be for making the menu items non-clickable if you use the WordPress custom menu scheme and set the placeholder links to “#”. This isn’t actually possible when using pages, so the solution would require some modification here. I have no doubt that this is doable, but I don’t know if this rates high enough on my list at the moment to go poking through the theme and WordPress PHP until I can figure out how to do this. If I have some downtime, it might be interesting, and I’ll make another post about it if I do.
I was looking around for ideas about what to do for 404 redirect for the site. My personal favorite is the “You 404’d it–gnarly, dude” message, but copying that seemed in poor taste for some reason. As I was looking, I stumbled across a solution that didn’t occur to me. It’s simple, elegant, and easy to put into place.
I’m not sure if ilook is Christopher Carey or not, but kudos to both if they are not one and the same. This is a solution to a problem that I wasn’t aware of. I personally think redirecting to home is a more elegant solution than a 404 page in and of itself, even if you provide a nice message and search on that page.
If you’re wondering where to stick that PHP in a word press site, it goes in your active theme’s folder in the 404.php page. You can edit this through SSH or, if you don’t have access, through the word press control panel’s theme edit section (clicking the 404 page editor on the link at the right).
Cheers!
About Me
I am Erik Dietrich, founder of DaedTech. I’m a former programmer, architect, and IT management consultant, and current founder and CEO of Hit Subscribe.
