-
ODT Gun Show & Swap Meet - May 4, 2024! - Click here for info
Site is very sloooooowww....
- Thread starter fotog54
- Start date
Download speed tests are not the same as web page loads.
Other sites you've tested may have content delivery networks (CDN) in place. That's when the site's resources are cached in a network of servers, typically all over the world. So, if your VPN is a server in San Fran or Munich, the VPN may be getting some or all of the assets for other sites from a server that is much closer to the VPN than ODT is.
Because most ODT traffic is in the southeast, and a higher percentage of that traffic is from Georgia or near-Georgia residents, the number of router hops required to assemble all of the content for a page is much less than it would be for access from a distant location.
Try doing a geolocation with your browser, to see where your current VPN presence is. The farther away, the more routers each packet has to traverse to get to and from ODT to your browser. It makes a difference.
its like bump stocks try to create a work around and all kinds of **** pops up.
It looks like the Service Worker's attempt to cache things just doesn't want to work when on a VPN.
This attempt to load this post just stopped at this point, and it rendered a blank page with no content. Subsequent page loads (eventually) loaded without the Service Worker being used, and that worked fine.
I'm in Dalton using a VPN connection through Atlanta. So, I'm not hopping all over the world here.
I would recommend moving all of the caching in the Service Worker to a more traditional and simple PHP page that can handle caching on the backend. Trying to cache via javascript on the client side is never going to be as reliable as a backend solution because there are too many variables to deal with (browsers, devices, versions).
This attempt to load this post just stopped at this point, and it rendered a blank page with no content. Subsequent page loads (eventually) loaded without the Service Worker being used, and that worked fine.
I'm in Dalton using a VPN connection through Atlanta. So, I'm not hopping all over the world here.
I would recommend moving all of the caching in the Service Worker to a more traditional and simple PHP page that can handle caching on the backend. Trying to cache via javascript on the client side is never going to be as reliable as a backend solution because there are too many variables to deal with (browsers, devices, versions).
A lot of ya'lls Internet providers throttle your a**.'
Okuma , did you do something? Site is screaming fast at home ISP for me all of a sudden.
Not sure what was changed, but the service worker is still there. The site is MUCH faster over VPN this evening. In fact, this post loaded sub-second. If there was a change, it was a GOOD one!
Post I was on earlier loaded (fully) in 1.42 secs over VPN from Dalton through Atlanta:
We didn't make any deliberate changes relative to site performance. We routinely apply OS and control panel updates to the web and database servers, which can have an impact. That happened twice this week, so I can't rule out server-side related difference, For the vast majority of visitors, the site's performance was good before any such updates.
Service worker js script likely isn't the issue, as that's part of the forum application stack and hasn't changed.
It could also be something the data center did, without regard to ODT: Perhaps nullify a bad route that other data center residents were complaining about. That's where I'd place my bet.
We have numerous monitors watching the site's uptime and performance. Since the last round of major forum updates and changes (in 2022), the performance has been very consistent. We have the stack tuned to the point where a high percentage of visitors have a good performance experience, including during higher traffic periods.
Glad those of you using a VPN are enjoying better performance. Maybe this discussion rattled the NSA and they shut their packet sniffers down.
Service worker js script likely isn't the issue, as that's part of the forum application stack and hasn't changed.
It could also be something the data center did, without regard to ODT: Perhaps nullify a bad route that other data center residents were complaining about. That's where I'd place my bet.
We have numerous monitors watching the site's uptime and performance. Since the last round of major forum updates and changes (in 2022), the performance has been very consistent. We have the stack tuned to the point where a high percentage of visitors have a good performance experience, including during higher traffic periods.
Glad those of you using a VPN are enjoying better performance. Maybe this discussion rattled the NSA and they shut their packet sniffers down.
