Many people have been complaining about slow loading social widgets. You know the ones! I’ve written a WordPress plugin which may help, but there are some issues related to it and I’d like some advice. I have some specific people in mind, so I’ll ping them below.
UP TO DATE INFORMATION ABOUT THE CURRENT STATUS OF THIS PLUGIN CAN BE FOUND AT THE IFRAMEWIDGETS PLUGIN HOME PAGE
I’ll put in a disclaimer right now: I am not having a go at the slow widgets themselves. They are not slow all of the time or for everyone. I’d like them to be faster and I’m sure the social sites are doing what they can to improve performance. However, they are a problem for some people and I am looking for a workaround for these people.
What Does The Plugin Do?
The plugin creates IFrame widgets for WordPress. They are similar to Text Widgets, except output is created in an IFrame (in the sidebar). So, placing social widget code in an IFrame widget means it will appear in an IFrame.
The benefit of placing social widgets in an IFrame is that IFrames load in parallel to the rest of the page. If the social widget loads slowly or hangs, it won’t prevent the rest of the page from loading.
In addition to this, the plugin provides other features / benefits, including:
- Widgets remain hidden until they are completely loaded, then appear in whole. If they don’t load, they won’t take up any space on your sidebar.
- Up to 9 IFrame widgets can be enabled, but you don’t have to use them for all your social widgets, just the ones you are having issues with.
- Should work for any external widget, not just social widgets.
- Caters for the BUMPzee widget php code (other php code won’t work).
Want to see it in action? You can, right here on my site. The BUMPzee, MyBlogLog and BlogCatalog widgets are all running in IFrame Widgets. Sounds great right? But there are some problems / issues.
Issues With Social Widgets In An IFrame
The following are some problems / issues with this approach:
- The main problem is that links in the IFrame open in the IFrame. I’ve added target="_blank" to the IFrames which seems to fix the problem for the MyBlogLog widget but not the BUMPzee and BlogCatalog ones. Something in their widgets is overriding the IFrame. I’m looking into whether I can do something via javascript’s onClick event handler. This is a deal breaker for the BUMPzee and BlogCatalog widgets.
- Social widgets need to tell their website who has been to your site. If they do this through cookies, there should be no problem. I can now confirm that BUMPzee, MyBlogLog & BlogCatalog widgets all work fine.
- The social sites may not like people running the widgets in IFrames. I hadn’t considered this until I read Lucia’s post about Blogrush being unhappy with their widget being placed in the footer.
- IFrames are not great for either SEO or accessibility. This should not be an issue, as we are dealing with external widgets rather than content. It may even help preserve PageRank as the search bots may not follow the links. Can any experts out there confirm this? And how will this impact on point 3 above?
Don’t tell me IFrames suck! I don’t like them either. They were the last resort after it proved impossible to call the social widget code after the page has loaded (either by making an AJAX call or by creating the javascript in the DOM). This won’t work, as most social widgets use document.write, meaning they must run when the page is loading. Caching them on the server won’t work as the widgets won’t detect your visitors.
Feedback Please!
I’d like some feedback on the above issues from anyone willing to leave a comment. In particular, there are some experts I’d like to hear from. I’m shooting pretty high, but I’ll ping them and see if they respond:
First up is Scott Jangro, BUMPzee creator. Scott, if you read this I’d love some feedback from the BUMPzee’s perspective, especially on points 1 and 3.
Next is Andy Beard, who is an expert in… well pretty much all of this. Andy, I know you’ll probably say that themes need to be designed correctly (ie sidebars before content), but I’m very interested in your views.
Third is John Reese. John, I’d be grateful for your thoughts on point 3. Would you be concerned by the Blogrush widget being in an IFrame (if it was placed higher on the page, which is your main concern about it being in the footer)?
A special acknowledgement needs to be given to Earl Moore at Meandering Passage. When I turned to IFrames, I came across Earl’s Keeping javascript widgets from controlling your blog post. Earl, I’d love to know what you think.
I’d also like to hear from the following people who have had widget issues:
- Lucia at Big Bucks Blogger
- RT at Untwisted Vortex
- Chris at Blog Op
and anyone else with an opinion on this!
The Final Word
I’d really like feedback on this. I’ll probably release the plugin regardless, as it’s already written and I think it will have some use. However whether I push the social widget angle depends on your feedback (and whether I can solve the links opening in the IFrame issue).
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
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..
I am very excited and encouraged to watching your article. This article is very reliable & incredible. Heartily thanks for your giving out information.. Great site, and thank you for the quality.