I’ve had the problem that the embedded website (iframe) wasn’t up to date while the original website and the feed in NewsBlur already showed some updates. Maybe a problem with caching?
NewsBlur does refresh the page, but as you correctly suspected, the page is cached. Many publishers will invalidate the RSS feed’s cache, but not the page’s cache. And now that things are real-time, you know about a new story that much sooner than the page is updated.
Now, the site you’re linking to above is an odd case. Right-click on the site and go to Statistics. Check the very bottom of that dialog – do you see the Feed vs. Page fetch dates? Those should match up on 200s/OKs. And there’s a small chance that the page is being fetched even when the feed has not been updated.
For this feed, try Insta-fetching the stories to see if the problem goes away. If it comes back, let me know and I’ll take a look at the logs to see what’s going on with this one.
Well, I’ve already tried the insta-fetch option. So if I understand you correctly feed and website are separately updated? Shouldn’t the website always and only then updated when the feed has changed?
I’ve actually accessed the original view multiple times this afternoon and there were several updates only listed in the feed. So even if the website is only reloaded on demand, I think the statistics show a problem.
By the way that website was the only one which had some great perfomance issues at older Firefox/Chrome versions. Either the website is fixed now or the browsers. But shouldn’t influence the NewsBlur proxy process.
Ok, a bit of a mix-up on my part. What’s actually happening is that the page is only updated when there is a new story in the feed. There is also a 10% chance that the page is going to be fetched, regardless of whether or not there is a new feed (but only on a 200/OK).
Thing is, the feed is either pinging NewsBlur when it has a new story in its feed, or NewsBlur is hitting the feed before its own page is updated. This happens a lot, unfortunately. I could just schedule another update in 5 minutes if there is a new story, just to correct for this bug.
In fact, that’s not a bad idea. If there is a new story, come back in 5 minutes, otherwise just come back in the normal delay interval.
OK, now I understand. So the feed is, thanks to the Feedburner layer or at least different internal caching, faster updated than the heavily cached website.
Another idea is to check if the website has changed after the feed has. Might be simple by checking the return codes (200/OK and not 304/Not Modified) but I’m unsure how reliable this is. Or look up if the website already contains a link to the new feed entry.