This post comes again from a client request. They were using the Vertical Scroll plugin for WordPress. However, they needed this scrolling box to work on their multilingual site (Chinese & English). But with this plugin, there’s no shortcode, or way to include it in a translatable page. So, I wrote a really quick plugin enhancement. Check it out, hope you find it useful:
When you install WAMP for the first time, phpMyAdmin’s ‘root’ account does not have a password. So, when you’re trying to install WordPress it will give you an error saying it can’t make a database connection. In order to fix this (I’m in phpMyAdmin version 3.5.1), go to the “Users” section and click “Edit Privileges” next to the root user. Then scroll down and add a password.
Finally, stop WAMP services and go to C:\wamp\apps\phpmyadmin3.5.1. Edit the config.inc.php file and add a password (for me it’s on line 16):
$cfg['Servers'][$i]['user'] = 'root'; $cfg['Servers'][$i]['password'] = 'root';
Restart WAMP services and you should be ready to go!
I’ve been knocking my head against the wall trying to get the reflow table to work in jQuery Mobile 1.3.0. I just kept getting the spinning/loading icon. Finally figured out the problem:
The problem was I was setting up my tables like this:
<table data-role="table" id="schedule-table" class="ui-responsive"> <tr> <th></th> <th></th> </tr> <tr> <td></td> <td></td> </tr> </table>
Instead, you need to include the THEAD and TBODY wrappers around your rows that contain either header cells or body cells, respectively. So now my table looks like this, and it works great:
<table data-role="table" id="schedule-table" class="ui-responsive"> <thead> <tr> <th></th> <th></th> </tr> </thead> <tbody> <tr> <td></td> <td></td> </tr> </tbody> </table>
This is probably something that should be made clearer in the docs. I had to just look at the source code for the table they had on the Table: Reflow page.
I’ve been trying out the new 1.3.0 beta version (unstable release) of jQuery Mobile. I have to say, it has a lot of nice stuff in it. Still a bit buggy in my experience, but I’m still quite impressed.
Most exciting feature? Panels
Now you can have panels of content slide from the left or right of the screen based on clicks, swipes, buttons, or any other event. It finally solves the problem of long navigation menus without needing to custom code stuff (which is the point of jQuery Mobile in the first place).
The whole release is focused on building for responsive design. It’s quite difficult these days to really account for what kind of screens people are accessing your site on. With the release of devices like the iPad Mini, there really is a need for true responsive and fluid design. No longer can we really do with one or two breakpoints for “desktop” and “mobile”. We’ve got tablets, small tablets, netbooks, dual monitors, phones, and not to mention the orientation of horizontal vs. vertical on these devices.
Right now I’m in the process of developing a mobile version of a web app we developed last year. For the sake of speed and compatibility we’re going with jQuery Mobile. Since we have a few weeks to finish everything up, we’re pushing it out with 1.3.0. So here’s to hoping it’s at full stable release by our release date!
It’s tricky. On this project we’ve got to consider the a) public-facing website, the b) web app itself, and c) the mobile version (which does most, but not all of what the web app does). We’ve taken the approach of letting the mobile and desktop versions of the app talk to each other. When you’re on a page in the desktop version and you click “mobile site” in the footer, the system switches you to a similar page in the mobile site. Kind of interesting.
But what this all means is that there are 3 designs, 3 CSS files, and 3 sets of data and screenshots to update anytime anything changes. As time goes on we’re talking about combining the web app and mobile app to one responsive design. But one of the things we’re running up against is the amount of data that is served up to the user. We’ve got a few areas of the app that pull in large amounts of data to sort through and add to their account. For mobile devices this has to be completely re-configured so we don’t drain the data plan or waste the user’s time.
Just a bit of rambling, but that’s where I’m at with responsive design and jQuery Mobile in general.
I was recently working on a project to bring down the page load times for a client’s website. The main functions of the site are to sell a handful of products, as well as bring in traffic for several popular keywords. The site also gets pretty good Adsense revenue, as well as making money from several affiliate links on pages. He has a lot of traffic, but sales and ads don’t reflect what he should be getting for the amount of visitors. I attribute a lot of this to the page load time. Every web marketer under the sun will tell you that faster page loads almost always means better results, whatever it is you’re hoping to achieve. There is no calculated benefit to somebody waiting for your page to load. The risk that they close the tab or click “back” while they are waiting is just too high.
This website is built in WordPress, has about 400 posts and 11,000 comments (yeah, a lot of comments!). On average the site gets about 5,000-7,000 visits per day, and the page load times (according to Google Analytics) were around 20-25 seconds. Terrible! Tests on GTmetrix and Pingdom (while both slightly lower than Google Analytics) confirmed the page load times were really high (around 19 seconds in many cases). Something needed to be done. My goal was to bring page load times to around the 5-second mark. The client didn’t want to spend much money on optimization, so that was also something to consider.
Step 1: Caching
WP Super Cache is installed on the site, and has a few settings applied to at least serve cached pages to the visitors. This didn’t help much with page load time, but it did mean the server wasn’t quite so busy producing fresh pages every time a visitor landed on the site. Personally I use W3 Total Cache on my site, but I’ve also had good experiences with WP Super Cache. Check out this post on how to correctly setup WP Super Cache.
Step 2: CDN (Content Delivery Network)
The CDN we chose for this was MaxCDN. For the 1st Terabyte it was $40, and with a coupon code for 25% off it was even cheaper. Setup was quite simple. Once it was setup, back to the page speed tests.
Before the CDN: 75% of “time spent per domain” was on the website. Meaning that for every 10 seconds the page took to load, 7.5 seconds of that time was being spent loading things from the website’s own server.
After the CDN: 6.45% of “time spent per domain” was on the website. So in plain English, this means that since we “outsourced” all of the big files off the server, that for every 10 seconds loading the page, less than a second was spent on the domain’s actual servers. This is huge!
Now, that being said, I didn’t notice a huge drop in page load speed. I was puzzled by this, but still happy with the results of the CDN. At least we narrowed down that now almost no speed was being lost by waiting for the Malaysian servers to respond. On to the next step!
Step 3: Trimming down server requests
The average page on this website had well over 150 server requests. This means every time the page was loaded, the browser had to go grab 150 different files from dozens of different domains. We needed to trim this down. We had already slimmed the site’s own server requests by offloading them to a CDN, but there were a lot left to deal with. A lot of these requests were because of WordPress plugins. We used P3 Plugin Profiler to cut time spent on loading plugins in half! Plugin bloat is one of the leading causes of WordPress heart attacks, don’t let it happen to you!
Step 4: Social
When an average blog post on the site is loaded, it loads the following:
- sidebar – Facebook Like box (with 12 faces showing)
- sidebar – Twitter feed (latest 10 tweets)
- sidebar – Feedburner count
- post – +1 button
- post – Facebook “Like” button
- post – Facebook Like box (with 12 faces showing)
- theme – floating +1 button
- theme – floating Like button
I’m sure I’m missing something, but you can see there are a lot of calls involved there. For Facebook alone the browser was making 48 requests. So Facebook accounted for over 32% of “time spent per domain”. For every 10 seconds spent on the page, 3 seconds were spent downloading stuff from Facebook! Now, one thing we need to think about is value of these things. This site depended heavily on social networks to get the word out about their products and bring in traffic. The Facebook page alone had close to 4,000 Likes, not to mention all the Twitter followers, Feedburner subscribers, and +1′s. So we couldn’t just take all of these items off. We needed to be deliberate and thoughtful when it came to analyzing the value of these social requests. In the end we left most of the social features enabled, but did remove a floating social icon box. That lessened the requests by a few. Can’t hurt!
Step 5: Intense Debate and WordPress commenting
Found it! It turns out that comments actually ended up being one of the biggest strains on the website.
The site was very popular, and received sometimes hundreds of comments per post. In fact on one of the site’s most popular products there were over 500 comments. The comments were great credibility to the site and product, so removing them outright would be a bad move. So instead of removing, we tried a few different things. First, we disabled IntenseDebate and just tried out WordPress’ default comment styling. This proved…pointless. It meant a few less calls to external sources, but in the end it didn’t save any time.
HOWEVER, I discovered something critical during this part of the process. And it has to do with the link between WordPress and IntenseDebate. The IntenseDebate settings were such that when WordPress loads the comments into the page, IntenseDebate takes them and formats and “pages” them (10 per page in this case). What I didn’t realize until I disabled IntenseDebate was that WordPress did not have its own limit set on “comments per page”. AHA!! So, this one product page was literally loading 500 comments, and then IntenseDebate was just reformatting and paging them to show 10 at a time. So I went to Settings > Discussion and set WordPress to split comments into pages with 10 comments per page. Save, refresh, tada! Now WordPress gave only the 10 comments to IntenseDebate that it was looking for. Instant boost in page speed! This may have been the single biggest drag on the system!
Step 6: Comments and Gravatars
A big reason there were so many requests the browser was making was also largely because of the amount of gravatars used in comments. For these tests we disabled gravatars both in IntenseDebate AND in WordPress. And when a gravatar was unavailable we used the “Blank” avatar. I think enabling the gravatars should work ok, as I’ve heard of a few plugins out there that will cache the gravatars on your site. These images would then in turn be cached by the CDN, therefore speeding everything up once again. But that is a test for another time.
Results: Comparing page load time using Pingdom
Here are my stats on the page load times of 3 pages (home page, the most popular post, and a random post) both before and after the above-mentioned changes. Pingdom allows you to compare three different cities (New York, Dallas, and Amsterdam). So the numbers below are averaged from all 3 city results.
Before: 151 requests 1.13MB 19.9 seconds
After: 135 requests 0.91MB 4.06 seconds
15.8 seconds saved (page loads 79% faster)
Before: 196 requests 1.30MB 11.51 seconds
After: 173 requests 0.97MB 4.8 seconds
6.71 seconds saved (page loads 58% faster)
Before: 200 requests 1.47MB 9.73 seconds
After: 182 requests 1.1MB 6.58 seconds
3.15 seconds saved (page loads 32% faster)
Google Analytics Page Speed
And finally, according to Google Analytics these changes have netted a 6.09 second sitewide average savings. That means site-wide pages are loading 27.9% faster than before.
So I didn’t necessarily reach my goal of 5 seconds per page, but we got pretty close. And when you factor out all of the non-targeted countries (client mostly wanted US clients), it was an acceptable change.
I’ve seen a lot of blog posts talking about CDNs, server requests, social plugins, etc. They all talk about how you’ll boost your site load speed by incredible amounts. I’m not really sure I buy it. If you’re dealing with a really bland site that has very well performing plugins, this may be true. But web design is messy. Once you hand a site over to a client, they may get their grubby little hands (meant in the most respectful way possible!) all over it and start doing things that seem to be good ideas. So, as I said, analyzing and optimizing your page load time is a sticky process. It takes weeks, months even to get it right. And then go and add some random plugin, and you have to start pieces of it all over again! But personally, it’s a challenge I love.
Have any tips on optimizing WordPress for faster page load time? Let me know, every site is a work in progress!
Side note: read this on how to set your page load sample in Google Analtyics.
I’m attempting to find one tool (maybe it’s not out there) that will allow me to manage my projects (to-dos, timelines, milestones), along with being able to invoice clients of those projects. I don’t track hours, but I do need multiple currency support. Currently I’m using FreshBooks, but it (naturally) doesn’t have any kind of extensive project management tool (other than a light, ‘time-tracking’ piece). Here is my list of products I signed up for today (all the free trials), and my quick comments on why they don’t quite do what I need. If I’m missing something, or you’ve heard of something better, let me know!
Basecamp – No invoicing, but I like the project management side of things
B2Bee – Can’t seem to import basecamp projects
Crisply – Can’t do invoices without time tracking
Harvest App – No Calendar to track project timelines/milestones
Invoice Machine – Couldn’t import from Basecamp
Invotrak – couldn’t test it fully with trial version
Solo – Difficult to understand, but might work. Bad currency support
Subernova – hard to use
Zoho – Not sure if invoicing and projects are one package together, waiting to hear back
Don’t get me wrong, almost all of these apps seem to work great for what they do, they just don’t work for what I need to do. So try them out and see if they’re what you need!
I’m going to stray real quick from my typical posting topic of web development and let you in on a great site I’ve found for all my consulting and freelance work. It’s called Freshbooks.
I store all my clients and projects on the site, and am able to quickly produce, send, and track an invoice for a project (or part of a project). It makes accounting a lot easier, because you know in one click how many invoices have been paid, how many have been partially paid, and how many are still at 0% fulfilled. One of the nice things for me too is that each invoice can be tailored to match the currency. So whether I’m billing in $ or 元, my client sees what they need.
Another part of the beauty of Freshbooks is that clients can (if they wish) pay online, and even login to see all of their current and past invoices.
All in all, it’s a great service. And you should sign up today!