47 Responses to “New WordPress Plugin To Help Slow Widgets – Maybe”
This page contains comments from the New WordPress Plugin To Help Slow Widgets – Maybe article.
Click the icon
to subscribe!
Subscribe
to subscribe!
Stephen Cronin is Manager of Online Service Delivery at a Queensland Government department & has been a freelance WordPress developer/consultant since 2007
*Content on this site is my own and is not related to my employer
Hire me - I'm expensive, but I'm very good!
WordPress Plugins
- DualFeeds: Offer both full & summary feeds to your readers!
- IFrameWidgets: Stop slow javascript widgets breaking your page!
- FeedEntryHeader: Add copyright info to the TOP of your feed!
- LocalCurrency: Show values to readers in their own currency!
- KeywordLuv: Reward commentators with keyword rich links!
- Comment Warning: Detect potential spammers and warn them!
- Eclipse Crossword Integration: Publish crossword puzzles!
- Ajax_the_views: Make WP-PostViews work with caching plugins!
- Remove Widget Titles: Remove widget titles on the front end!
Want a Custom WordPress plugin? See my Services page.
Greasemonkey Scripts
- Google Numbered Search Results: Number Google SERPs
- Bing Numbered Search Results: Number Bing SERPs
- Disable Ctrl-W: Disable the CTRL-W key so you don't lose work
- markItUp! for Greasemonkey: Enable markItUp! for text areas
Visit my home page at Userscripts.org.
I read Earl Moore’s information as well. What MyBlogLog uses as a target attribute is “_top”. Both BlogCatalog and BUMPzee use no target attributes at all. Is it possible to add a target attribute to their links within the iframe?
If you can get the iframe solution to work in all cases, I’m all for it.
I think a better solution would be to use WP Super Cache, you can reduce the expiry time to something like 600 seconds(10 minutes) or 300 Seconds(5 minutes), but it really does making the loading time fast, plus it keeps your server free of hundreds of database queries all the time!
Abdul, with respect, you’re wrong. Super cache won’t help with this because it’s not PHP or your server slowing things down, it’s JavaScript files loading from an external server (such as BlogCatalog).
Oh, I get your point. Thanks for clearing it up!
No worries Abdul, Thanks for stopping by.
Hey Stephen.
First of all, my apologies for my part in your having to create this at all. I know the BZ plugin definitely has it’s slow moments, including this past weekend. I’ve just added a bunch of caching and improvements this morning. I hope you notice an improvement.
I would have put this widget in an IFrame if the size wasn’t variable based on the user’s configuration. How do you address that? I see you doing some tricky stuff with Javascript here. Is it a hardcoded height per widget?
(And in fact, the Bump button widget is in an iframe.)
To your questions…
Personally, I have no problem with you doing this. Makes no difference to me.
And I can look at making it an option or even standard to put target=_blank in the links.
I think this is a great idea Stephen. Slow widgets are a major issue, and if this mitigates the problem, that’s fantastic.
Actually a while back in a discussion on Jeremy Zawodny’s blog about MyBlogLog, people were talking about using caching for widgets.
One of my favorite universal plugins is Inline RSS, but it can actually be used to pull in any data you like and display it, with caching.
http://www.iconophobia.com/wordpress/?page_id=55
Before MyBlogLog improved their loading time, I was going to propose people use this script, or a variation to include widgets.
The worst for me are actually Digg buttons and other voting widgets.
Yes, I do believe themes should be designed correctly, content first but CSS does have vertical limitations, such as the difficulty in placing something in a bottom right corner with content flowing around it without using javascript.
Oh, actually there is a problem with this.
Any widget that relies on http_referer (for collecting stats, etc.) is going to get this page:
http://www.scratch99.com/wp-content/plugins/iframewidgets/iframewidgetspage.php
I still don’t have a problem with it as load time is most important, but it’s going to screw up your page view stats.
Maybe offer an option to split the code.
What MBL do is they have tracking code, and widget code that includes tracking
But, if you have already loaded the tracking code, then the tracking code is no longer loaded with the widget.
Thus I am quite happy to have MBL tracking loading in the header, and the widget loading very late on a page.
Sure, and I didn’t mean to suggest that I couldn’t or wouldn’t do something to fix this on my end.
I’ve actually got the tracking code separated into it’s own JS file, to enable tracking even without a visible widget.
I wonder if MBL can detect if the tracking code was already executed when the visible widget is in an iframe.
I didn’t mean to suggest you wouldn’t
, was just jumping the thought process because in the past I had an email discussion with Eric formerly from MBL about this.
I will give Daniel from BC a shout on this, and might be able to drum up someone from MBL as it would be great if everyone supported it.
Do Iframes work inside iframes ok? I would love to stick some buttons in a universal Iframe.
I’m all for any plugins that helps with these widgets. I’m a bit swamped for time in the short term.
We do need to hear from John Reese, because he has a widget. I’m not sure if it’s slower than Bumpzee, but the fact is, it’s difficult for bloggers to deal with and test all these widgets separately.
(I have other issues with Blogrush, and I’m thinking of posting and detailing just how poorly targeted it is on my knitting blog. But in the short term I have other priorities!)
Sounds like a genius idea to me – I’m only on the web for 10 mins tonight, but I’ll definitely give it a try & let you know what happens at my end.
Actually, I’m pretty sure that the offending widget on MY blog for the past couple days has been MyBlogLog. It’s definitely a pain when these things cause slow-loading problems. On the other hand, occasionally AdSense causes page-loading issues as well…and so far, I found a way to live with them.
Thanks everyone for your feedback. I’ll start with quick responses in this comment, then more indepth responses to Scott and Andy in a subsequent comment.
RT, I’ll have to look into it further. I’m guessing that for the plugin to truly work well, it will need involvement from the widget creators. If Scott can help out from BUMPzee’s end and if Andy can get someone from BlogCatalog and MyBlogLog on board, then it all looks much more likely. Otherwise, it will probably work for some, not for others and only partially for most. I’ve seen your post (pingback above) and for the record, in truly imaginative fashion, I’m planning to call it the IFrameWidgets plugin.
Lucia, thanks for your feedback. I agree that it would be good to hear from John Reese. There’s still a chance he’ll respond, but he was always a bit of a long shot (at least I visit Scott and Andy’s blogs, I’d hadn’t been to his before). If he doesn’t respond, then I’ll look for volunteer beta testers or I’ll join Blogrush myself (I haven’t had the time to do so yet).
Chris, thanks also for your feedback. I’ll see if anything can be done about the issues first, then I’ll release the plugin (if issues can’t be fixed, I’ll explain what they are and their impact and let people make their own mind up). Having said that, if anyone really wants it now, I’m happy to give it to them, just let me know.
Chuck, I find they take it in turns! For me, most of the widgets work fine, most of the time, but then one will get bogged down for a week or so, before it picks up again. I guess thats the price of expansion. As these services become more popular it puts a strain on the service, until the infrastructure is upgraded. As users, we have to accept that. This plugin will hopefully ease the inevitable ‘bogged down’ times.
Stephen,
I’m willing to beta test if you would like. I’m really getting tired of slow social site widgets. Until I read Lucia’s post I was considering removing them, and writing a bad post about them, but you have given me hope.
I’ve put the target=”_top” in the BZ widget links. Looks like it’s clicking out ok now.
Scott, Thank you very much for your feedback. I really appreciate it. And there’s no need to apologise, at least to me. Sure, people get frustrated with slow widgets, but I for one am grateful that BUMPzee exists in the first place. People shouldn’t take that for granted.
The height of the IFrame is set to 0 when the IFrame is created. It’s then resized via javascript when the IFrame finishes loading – It detects the height of the IFrame’s content and resizes it to that. So the height should always be correct. However, I’ve just discovered this doesn’t work for Opera (it’s fine for Firefox, IE6 and IE7), so I’ll need to look into that.
The width is set to 100% of the available space (ie the width of the sidebar). This seems to be good enough in Firefox, as any extra space not taken by the widget is the same colour as the sidebar’s background. In IE6 and 7, the extra space is white. When I try to resize the IFrame’s width using a similar technique to the height, it doesn’t work. If I can’t resolve this, I will simply add a width parameter for the user to enter the widget’s width (for each IFrame widget). This should be sufficient because I haven’t seen widgets with dynamic widths.
Re links opening in the IFrame: I’ll see if I can do something via javascript that will work for all widgets, but obviously it would be great if there was an option to make the BUMPzee widget links use target=_blank.
Re http_referer: I thought my stats looked strange!.
. The numbers for This Page and Blog Total are now the same (because they are all looking at iframewidgets.php page). Point 2 in my post was originally much longer saying my plugin would work if the widgets just used cookies, but would cause problems if they used http_referer. I took that out after the BUMPzee, BlogCatalog and MyBlogLog widgets all showed visitors to my site. I assumed they didn’t use it – so I jumped the gun there.
If you can come up with a way to get around this, as per Andy’s suggestion, that would be great! Also note, that while I’d obviously like to get my plugin to work and have people use it, I’ll have no problem if you just want to build this into the BUMPzee widget and bypass the middle man.
I think I’m going to need to make the plugin available so people can have a closer look at what’s it’s doing, try it out etc. I’ll get it up on my site as a beta asap (maybe a couple of hours, maybe a day depending on the outside world).
Andy, thanks very much for your feedback as well. If you could get someone from BC and MBL involved and get this working properly, that would be great! As per my comment to Scott, I’ll get the beta up asap. Let me know if I can do anything else.
I read the comment on Jeremy Zawodny’s blog too:
I don’t see how this works, at least for BUMPzee and BC. How do these widgets communicate with their respective sites to update who’s visited you? I’m assuming it’s done via cookies. If that’s the case then the widgets need to be called via the visitor’s browser, not through a cron job on your server.
Now that I know that MBL has separate tracking code (thanks for pointing that out, I knew I needed your advice), I could see this being done for MBL…
IFrames inside IFrames? Hmm… Should work, an IFrame just shows another page. If that page has an IFrame itself, well that’s just part of the page that will be shown. Notice that I don’t seem too confident? I’ve never tried so can’t be sure that there won’t be some issues with it.
Scott, I missed your latest comment while I was writing the above response. GREAT! The links works fine now. Thank you for doing this so quickly – I find it quite amazing to get such supportive and proactive response!
Another potential issue though: I’ve noticed that I am now appearing in the Bumpzee widget on my own site. I guess this is related to the http_referer?
Scott, sorry, I just read your post (ping above) announcing the changes and I see that my avatar is now supposed to appear! It seems I’m a step behind this morning.
I’m glad to help. this was a simple one.
Your appearing in the widget is actually an intentional change I made this morning. I was in doing some performance fixes and thought why not show it? I like seeing your picture on your blog. Let’s not hijack this discussion with that discussion though, I mentioned it in the BZ blog (trackback above) if you want to give feedback.
And thanks for the details on the height adjustment on the iframe. I really do think I’d like to get the BZ widget into an iframe. Slowing down people’s blogs keeps me up at night, both literally and figuratively. I’ll watch for your progress with the opera issues.
And I need to think more on separating the tracking from the widget such that it’ll work with the iframe. That one will need some time and testing.
Eaglehawk, Thanks very much for your offer to beta test. I’ll have a beta version up anywhere from 2 to 24 hours (I have to go to work soon). I’ll email it directly to you when it’s ready.
There’s one more feature I want to slip in first: the ability to define width for each IFrame widget. This is needed to address the problem with IE showing white background if your widgets are thinner than the width of your sidebar.
Scott, no problem with the height adjustment stuff. I won’t go through the code here, you can see it in the source (and it’ll be in the plugin beta). The first if statement in the ifwChangeHeight function is for Firefox, the second is for IE. Any questions, just let me know.
I’ll wait to see how you go with separating the tracking from the widget. I understand it’ll take time and testing. I’ll let you know how the Opera issue goes (but that’ll take me some time too). Thanks again.
Hi everyone. The beta version is now up on the IframeWidgets plugin home page. Feel free to download and try it, or dissect it (please let me know how it goes). In the meantime I will be looking into a couple of issues (Opera and a javascript solution to links opening in the iframe).
I put the page together quickly, but I tried to list the current situation as it stands. Apologies for any inaccuracies or things I’ve missed.
I eagerly look forrward to this plugin. Anything to make my pages load faster is a good thing indeed!
G-Man
Great idea Stephen, I’ve seen a lot of different solutions for preventing widgets from effecting load time but this is by far the easiest and probably most effective. I have added the _top target to all of our widgets as well and am looking forward to testing out your plugin. Thanks for all your hard work.
Excellent plugin idea, Stephen. I am going to give this a shot tonight. I have been meaning to move these widgets to the footer and your plugin might moot that necessity. Thanks for the great work!
I will let you know if I see something weird. Also, it is really nice to see the interaction with people in the know.
Daniel, Thank you very much for doing this so quickly! Links in the BlogCatalog widget now open in the main window, instead of in the IFrame. I’ve updated the BlogCatalog section of the IframeWidgets plugin home page to show this.
One question I still have about BlogCatalog is whether you use http_referer at all (as BUMPzee do – see comments above) and if so, what is the impact on running the BC widget in an IFrame?
Thanks again for your help. I’ve added you to the acknowledgements section of the plugin’s home page along with Scott Jangro and Andy Beard. If you haven’t already got it, the beta is available on the home page.
It’s probably better for this conversation to happen on this post rather than on the plugin’s home page (everyone’s subscribed here and in a years time we don’t really need this correspondence showing on the plugins home page). However, I’ll keep the status of issues updated over there.
I’ve also heard back from eaglehawk who is beta testing the plugin. He can confirm that the plugin works on WordPress 2.3 (I haven’t upgraded yet). I’ve updated the plugin’s home page to show this and to add eaglehawk to the acknowledgements section.
G-man, Thanks for stopping by, I hope we can get this plugin to the point where it can be of help.
K, Thanks. Let me know how it goes. One of the things which has really impressed / surprised me is how quickly BUMPzee and BlogCatalog have not only gotten involved in the discussion but have actually made changes to help the plugin work. It’s truly amazing to me.
Regarding browser support:
I’ve confirmed this works in Safari as well as Firefox 2 and IE 6 & 7. I have got the resizing to work in Opera (meaning the widgets now display in Opera), but there is one issue:
The IFrames are supposed to appear when the content in them has fully loaded. In Opera, they do not appear until the entire page has loaded. If something (including another IFrame widget) holds up the page, none of the IFrame widgets will appear until everything has loaded or given up, then they will all appear. This does not occur for the other browsers.
At this stage I’m not sure what, if anything, can be done about it. I need to look at some other issues first.
I’ve added this information to the plugin’s home page and put v0.11 of the beta up for download (containing the new code for Opera)
Actually, I think I cracked the Opera issue by calling the resizing function from within the IFrame page. Seems to work, it’s live on my site, but not in the download. I need to test it a bit further, but will be offline for a while now.
I’ve solved the links opening in the IFrame issue, by simply adding
<base target="_blank">in the IFrame’s head. This means this will not be a problem for any widget. Thanks to Scott and Daniel for adding _top (which will override the base value by the way), but we won’t need other widget producers to take any action to avoid the problem. Sorry Scott and Daniel for not finding this earlier.I’ve changed the plugin so that the IFrame’s background will be transparent in IE and Opera (fine in Firefox and Safari by default). I’ve also added alignment options for each IFrame widget (theme’s default, left, center, right).
These changes will be in 0.12 beta, but it won’t be up for download for a day or two (out of time now).
I was wrong on the Opera resizing issue (it resizes the IFrame before it’s finished loading and cuts the BUMPzee widget in half). There appears to be no way for Opera to take action when the IFrame has finished loading. I’ve decided that Opera users will have to wait until the page has loaded before the IFrame widgets appear (which is what happens now).
So the only problem left is the http_referer one. Apart from that I think the plugin is close to being ready.
Latest version 0.13 beta is up on the plugin’s home page. I’ve added the changes mentioned in my last comment, as well as Tracking Code option for each IFrame widget. This will insert the Tracking Code into the Head section of the page. At the moment, only MyBlogLog has a tracking code, but if any other widgets create one, then the plugin is ready.
I think I’ve done everything I can, unless anyone else any any more ideas. Let me know if you do!
I’m willing to beta test if you would like too.
Television, anyone can grab the beta version from the plugin’s home page. You’re welcome to try it out, although I think there’s only one issue left – and it’s one that can’t be resolved at my end.
It’s best to read the information on the home page – it explains the problem, so you can decide whether it will worry you or not. If you use widgets not on the list at the home page, or if you have any problems, I’d be very interested to know. Thanks.
Update on IFrameWidgets:
I was about to release it, when some minor bugs were reported. As a result the 0.14 beta is up on the plugin’s home page.
The changes are mostly to eliminate XHTML Transitional validation errors (note there are two I cannot eliminate without compromising the plugin’s functionality). It also eliminates a PHP warning that appears if no widgets are set up and no longer displays $before_title and $after_title if the title is blank.
Thanks to RT for finding these issues and helping me fix them.
Hmm…doesn’t seem to change much. Might be that I haven’t used it much yet. I’ll see how it goes for a couple days.
It won’t make the page load quicker (it won’t say Done until the last javascript widget loads or gives up) and the slow javascript widget itself isn’t any quicker.
The benefit is that normally, everything after the slow widget stops and waits until the slow javascript widget loads. This can break your page layout and mean that other content is delayed from being shown (or sometimes doesn’t appear).
IFrameWidgets helps by allowing the other content (after the slow javascript widget) to load immediately, rather than waiting for the slow item to finish.
So if the slow widget is the last thing on your page, you won’t notice much difference. If it’s the first item, you’ll notice a big difference.
I hope this makes the plugin’s purpose clearer. If you are having any specific problem with it, please let me know and I’ll be happy to look into it.
Thanks Dude! You are one Smart Cookie! You get my base! LOL
I am sure Andy is proud of you..:)
Core Hacker to the Bone!
great plugin I avoid widgets for this reason I hate going to sites and waiting while it is loading some widgets and stuff.
Hi,
I’m having a problem with this plugin:
In the control panel (/wp-admin/plugins.php) the title is black (where any other plugins have a blue title). And it does not show up in ’settings’ when I activate it.
I’m using PHP Version 5, anybody can help please ?
Hi Peter,
Two questions:
1) What version of the plugin are you using?
2) What version of WordPress are you using?
It’s probably an incompatibility between these two. If you can let me know the above information, I’ll hopefully be able to help you further. Thanks
I guess you do not have to ask if people want this widget by the response you have on the post. Great idea anytime you can speed up some of the widgets i am all for it.
You always have something good your writing about.
Stephen,
There are a couple more aspects of using Iframes that have not been mentioned. There are the legal issues of embedding another website within your own. I know this is rarely pursued in the courts, however it is a risk if this method should go bigtime.
The other consideration is SEO. Every time I have embedded an Iframe, I dropped rank in Google. I’m interested in feedback from others on this as well. Iframes are a convenient way of getting your affiliate offer on-page without getting the Google bot involved.
I am watching that people are not following keyword at the time comment still now….
Ok back to topic 1st line came to mind bcz of plug ins ok forget that but wordpress had improved a lot in recent years..It has best plug ins now…no problem at all with these plg ins..