Are you sure this isn't something more straight forward than you think? Maybe 50% of your visitors are using mobiles, and your mobile skin on 3.4 doesn't have ads? If 50% of your ads are really being loaded from elsewhere, then it should be simple enough to see what's happening by loading pages and digging into the code to see where the ads are loading from?
They may not mean 1/10 of a second though, that's why I'm suggesting doing some real user testing - they may mean 1/100 of a second or less, and at that point what would you prefer, time spent on that or time spent on bug fixing, new features, or optimisations which are far more significant?
Does it really make a difference though? You'd need to do some real-user testing to show that, and in my experience there's usually nothing in it when making this sort of change. I'm not saying it's not worth doing, but with only 24 hours in a day sometimes it's worth focusing on other things rather than spending a lot of time trying to get a better score on online speed testers.
Although online tests have a use, and point you in the right direction for best practices etc, they're not the be all and end all. The changes you describe have clearly improved those test scores, but I'd imagine that although they'll maybe improve the load by 100'th of a second here and there they'll make no noticeable difference to the user experience, which is the most important thing.
That's an unreasonable example. When it comes to development timeframes there has to be flexibility due to the fact that unforeseen issues, challenges and bugs can arise, either on a particular feature or one which precedes it in the schedule which would have a knock-on effect.
All seems fair, but reading the original post it sounds like IPS did the upgrade. That being the case, surely whoever did it should have checked the server environment, seen that it was using an ancient version of PHP and said it wasn't advisable to run the upgrade until that was sorted? That one simple check would have saved a lot of downtime, and a lot of work on IPS's part?
You're right, no-one forced anyone to upgrade, but IPS are selling the product as ready for production, non-beta so I don't think it's unreasonable for people to expect it to at least work without bugs which are apparently (according to the comments of some in here) ruining the experience of running or being a member of a forum.
You're right, and it's also true that they clearly state test sites aren't supported, but if they were supported, would more people then test their installs and solve problems on them before going live? That could then reduce the amount of urgent tickets on live sites, and in theory speed up the support process.
If you have so many people with 'my site is down' problems right now that no-one within the company can spend 15 minutes a day updating your public facing bug tracker, then clearly there's a major problem somewhere!
I did edit my original post as tbh I didn't fancy getting embroiled in this, but anyway. No-one is asking you to ignore anything, and clearly prioritising customer issues is the way forward, but to go to the extend of virtually leaving the public bugtracker untouched isn't helpful to either your customers, your potential customers, and surely therefore your business.
This may sound harsh Charles, but the truth is that when it comes to *most* software that is the case, when it comes to IPS software my experience is that it's not. Over 10 years of being customers has taught us that early versions of the software have too many bugs, so we always wait, and part of that process of deciding when to upgrade is checking the bugtracker.
I disagree to be honest, having tried them both I've seen no situations where SFS flags positive, and many situations where the Invision system misses very obvious spammers who have been listed in SFS and ProjectHoneypot many times.
Also, the implementation of the spam flagging is very messy within the AdminCP at the moment, flagging a user as a spammer when viewing the validation queue only seems to remove them from the queue, you then have to reflag them within the normal member view to get them properly moved into the spammer group, and the same applies the other way around as well..