In an update to the Adbrite loading problems that I mentioned a couple of days back I today had an email from Adbrite apologizing for the problems and giving an update on their server upgrade.
They pointed to a graph showing the outages in the lead up to the upgrade and the lack of problems since.
They say that they are adding more servers and upgrading load balancers still to ensure faster loading times.
As a result I’ve put Adbrite ads back on this blog and am hoping it will not slow things down again. The problem with the way that Adbrite runs their ads is that if they go down it impacts everything else on the page they are on that comes after it on the page’s source code. This is a problem in my eyes because it brings their publisher’s pages to a standstill every time they go down.
Hopefully it’s something they can continue to improve in the coming months.
In similar news – Text Link Ads have also sent an email to publishers in the last week saying that they did have similar problems earlier in the week. As a result they’ve provided publishers with new code that means that if their servers go down again that the page will continue to load. This means TLA publishers need to change the code on their pages (not a fun thing if you have many blogs like we do at b5).
I received the email from text-link-ads on Monday. We only have text-link-ads on two of our Blogs so I was able to replace the code within a couple of minutes.
As much as anything I think there’s a flaw with the design of some browsers (yes, dare i say it, even Safari)
Safari caused me the greatest headache when trying to view ProBlogger over the last few weeks – it would load half the sidebar and the header and nothing else for about 30 seconds.
It feels as if the browsers are loading things too much in sequence. It would be good if they loaded all local content (ie on the originating web server) regardless of external content. Having said that, Google AdSense doesn’t cause these problems – maybe it’s because they use iframes (I think?). Maybe the alternative is to re-order the website code to put calls to external sites as near to the end as possible – using CSS it should still be possible to position things.
This has happened with a number of services and it’s irritating when you have to rely on an external site if it stops your own site from displaying quickly. I have to say the PC version of Firefox always seemed to load this page without a problem.
I spent a lot of yesterday changing the TLA code around our 27 blogs. An added problem was that some of them were on the WordPress plugin method, and the rest on the PHP code insert. Given the problems we’ve had, and the opportunity to replace the code, I’d recommend using the PHP insert method rather than WP plugin, as the plugin doesn’t work in many cases.
John, what do you mean the plugin doesn’t work? It works wherever we’ve used it?!
As for the new TLA code… one guy I spoke to indicated that the new code hosed his site and he had to switch back to the old code.
Aaron, the plugin didn’t work on some of the WP 2.0x sites. The plugin just didn’t recognize the local-xxxxx.xml file on the server, and broke the blog completely. I used the PHP insert code for all the others and have had no problems.
With the new code, I’ve replaced the plugins on the 1.5 blogs with the PHP and updated the 2s. They all work perfecty without a hitch. Fingers crossed :-)
@Andy: IMO Google Chrome should be the best browser to handle this. Firefox is great but I just can’t help noticing its loading status bar.