I was doing tons of efforts to optimize my website, and while checking the performance reports, for tons of pages (including the home page). I could find that it gives these two “poll” requests that are taking too long to load, Is it a Poll plugin being loaded 
though non of those pages have the poll plugin in them being used and the user loading is anonymous.
Any insights would be appreciated, Thanks
No, it isn’t the poll plugin. What poll means in this context is kinda like “check the server to see what’s new since the last time checked” and then send it over in the “message bus”
AFAIK this runs every 30 seconds but I have never seen anybody here having a problem with it coming back slow.
Running some kind of unique set up?
Is the .3 seconds causing a noticeable problem for you?
nop, not unique setup at all…
and it’s not slowing down the website that much, but it’s being the slowest for sure. and made me wonder how really important it is. and whether or not can sacrifice it.
You’ve said it takes 30 seconds everytime, though those stats are from pingdome, and it’s just a single call the full time to load everything is around 300ms at the moment. and poll is being called twice at least during that time (or at a single call to the page).
It doesn’t take 30 seconds, it runs every 30 seconds.
You can’t really do without it. A lot of “updated information” is sent back. Notifications, new topics, post counts, posts themselves.
Yep I totally understand 
Since as mentioned it’s being called Twice on the initial page load, wouldn’t it make more sense to load fresh page (with all notifications, topics…Etc) on the first call. and then wait 30s before making another call to it?!
Or at least if it’s limited by the structure on wish discourse has been programmed on (which I believe it doesn’t), then a single poll call would just do.
The initial page load is typically the most expensive (exception maybe being an image heavy topic) because essentially the entire app is getting loaded. After that it’s the “live update” stuff.
Subsequent pages do not load in the entire app again.
Yep, exactly.
That’s exactly what I love about discourse, I know now that my initial web call takes 300ms, that means any subsequent call will take way much less. which is nice.
Thanks for your feedback @Mittineague
Note that these requests will not slow down your website at all, since nothing is waiting for them!
They are simple a way to keep an open connection to the server to implement push messages
Yep, they aren’t pausing the load.
Though I’ve noticed on the home page, when it’s loading those hundreds of user avatars, Discourse only allows a limited number of parallel loads, which causes for other requests to wait;
Maybe that can be increased as well, but It can lead to someone to abuse it costing me more server resources.
I believe that is a browser / OS limitation, but I’m not sure.
pingdom says it’s from server side. but not sure as well.
It’s “from server side” insofar as the server controls the fact that all requests are all going to the same domain, however it’s the browser that decides to make no more than N connections to the server in parallel. Since that’s never going to get fixed, just switch to using HTTP/2 (it should be built-in, as long as you’re using TLS) and everything will be much, much better.
thanks @mpalmer for your contribution, but could you please elaborate or give links… concerning this point below:
just switch to using HTTP/2 (it should be built-in, as long as you’re using TLS) and everything will be much, much better.
You can read about MessageBus here:
MessageBus is responsible for pushing live notifications from the server to the clients.
So, for example, as soon as someone 
's this message I get a blue notification on the top right. Or if someone replies this page will refresh right away with the reply.
MessageBus using long polling with chunked encoding, what this means is that a single 30 second session can push multiple messages from the server to the client.
The 30 second requests here are not a performance concern, payloads are tiny and the server is designed to handle this traffic very easily. Since you are using H2 it does not even eat up a connection slot like it would in the old days of H1. Once browser moves to a background tab message bus is smart enough to slow down its polling.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
