Hello Bubblers… Our app has all the sudden been showing excessive amounts of ‘Page Load’ events in the metrics.
For example, in a 4 hour period while in maintenance mode and the only user using the app, testing, tinkering, etc… The metrics show 60,000+ ‘Page Load’ events for the page I am working on.
Our app is an AI art app with image, video, chat generation capabilities.
What I was doing during this session…
Entering prompt, clicking to generate images (backend webhooks)
Communicating with an LLM, sending a prompt and getting a response (maybe 30+ times)
Clicking to view my media library (repeating group) every now and then
I checked the metrics for each of these actions/events, including loading the page to see how many ‘page load’ events are recorded and found nothing suspect, and only 1 ‘page load’ event.
Any ideas what might be going on, where I might look to get to the bottom of it?
If you have a lot of reusable elements on a page (including nested reusables) and they have a “Page load” event, they’ll be triggered aswell when the page loads.
What I mean to say is that the metrics show 60,000+ ‘page load’ events in a 4 hour period.
I loaded the page in question, made a few actions on the page, just to see how many ‘page load’ events are triggered to confirm it is only 1 as expected. Meaning, there is nothing in my loading of that page or the usual actions I make when using the app that is registering as more than 1 page load event.
I actually just saw a post you responded to some time ago with the same issue. In that instance it was assumed it was bots hitting the page, I have modified robot.txt to prevent them and see if that resolves it.
Do you know if there is a way to confirm it?.. or what else it might be?
Although this is a private page, I of course don’t want to block the index, it’s a bit concerning if the index page being hit by bots is gonna cost 60,000 page loads worth of wu in just 4 hours.
That was around 10,000 wu… I’d hit the limit in a couple weeks! LOL
What is also true is that every go to current page also triggers page load workflows.
So every go to current page action triggers OPL workflows.
If you have large actions in those workflows then you’re asking for trouble. You can gate workflows that should happen only once with a state, or a Do Only Once action.
Thanks. I’ve already done that, but it won’t help in this instance because it was confirmed the traffic came from my IP, though there is nothing in the metrics or logs that identifies what is triggering the numerous ‘page load’ events.
Page load is a client-side only event, so something is “refreshing” the page and, if it were based on a single user, 60k in 4h it’s over 4 page loads per second…
Search for Do every X seconds actions that might be running, check if there’s any javascript being executed on client-side pooling LLM response without a trigger to stop.
Have you installed any new plugin recently? If yes, try to temporarily remove it and monitor if this page load issue still happens, sometimes a window.location, history.go, window.open or other actions might be related to it
60,000 page loads would be almost the 10,000 WU, so this looks more like the page itself is being requested repeatedly, rather than just a workflow firing over and over.
My guess would be a plugin, iframe, media element, or some custom JavaScript making requests to the page URL in the background (4 requests per second sounds much more like a loop or polling than normal navigation).
I’d leave the Network tab open with “Preserve log” enabled and look for repeated requests to the page URL. The “Initiator” column might help identify what is triggering them.
I do not have any repetitive tasks (Do every), no pooling on the client-side, no new plugins. No ‘window.location, history.go, window.open’ events. There are no visible page refreshes or redirects.
Do you know if ‘page load’ only tracks a literal page load? …or might it track other activity as a ‘page load’?
Bubble support clarified that they found the majority of requests to our apps main page was likely from an < img > tag looking for an image but instead attempting to load the page itself. For some reason, continuously, in a steady interval.
I found out it was the ‘Better Uploader’ plugins ‘Preview’ element. Although it does not trigger the continuous event if the dynamic image reference on it is left blank by default, I had it getting the image link from a custom state. When the popup that contained the ‘Preview’ element was closed, I was clearing the custom state so when the user clicks to open the popup the ‘Preview’ element would be empty.
Setting the custom state for the dynamic image to blank, likely created an empty string “”, instead of null, which possibly caused the Better Uploader plugin to continuously look for the image, but since there was no link, it was defaulting to attempting to load the page.
Setting the custom state for the dynamic image link to a default image link instead of blank solved it.
