Poor Website Performance

[lordyavin]

What happened?

Since a while I experience very bad performance when navigating the site. I don't know where the problem is but as it did not disapear over time I'm raising the issue.

See attached logs: firefox-logs.zip

Sometime navigating to another crag, or starting to log an ascent or finishing a log the browser does nothing and waits for data served by site or third party resources. This makes the usage quite unresponsive even though streams are lazy loaded in the background.

I experience this issue on mobile and desktop.

What you expected:

• [ ] instant (<1s) response in a HTTP GET request for www resources
• [ ] instant response when sending form data (e.g. saving logs, or content edits)

[georg-d]

If it's not just the last 1-2 days but 2-3 weeks, I cannot share the impression. Only when I browse the page on a mobile phone (Android) at the crag where I usually have limited mobile coverage, I experience bad loading times / no reaction (probably timeouts) / error pages - especially causing a bad feeling while batch editing routes/cliffs as I never know which of the entered data has not been saved and thus might need to be re-entered again.

[lordyavin]

I'm not talking about days, I can't exactly say when my problems started and most of the time I just didn't care. I experience the bad responsibility since months.

A side note: I use a tracker blocking DNS server at home (pihole) and when I'm on the road I use Blokada for that.

[lordyavin]

Wow, just a second ago I waited ~5s until the mobile browser rendered something...

Does anyone know a good screencapture app for Android?

[rouletout]

If you report these issues can you please put the links of the pages you try to open and directly test with another connection as well. Eg using a WLAN instead of mobile network or a different browser or device and report. We monitor web-site performance quite strictly but havben't seen any degradation of performance over the board in teh last months so your input needs to be more detailed to be helpful.

[lordyavin]

Problem is that If I repeat to load the url again the cache of the browser jumps in. So it is not reproducible with an instant reload. I know that the issue happens using WLAN and 4G. Any hints how to log the performance are welcome.

[rouletout]

No worries about the cache - the idea is top test with a different device / network first and / or a different browser. You can also clear the cache if you want - if we can't reproduce any of that it is unfortunately of no use. Often we see such behaviour because of network access points or special settings on some devices (eg your blockers might also be involved).

[killakalle]

I can confirm that I often experience quite bad loading times of pages.

To be able to measure something I've used the Chrome Performance measuring tool while doing a simple navigation to a child node. In the screenshots you can see that it takes 20+ seconds to load the next page.

This was measured from my laptop at home. Here's a speed test right after the performance test

[lordyavin]

Thanks @killakalle

[rouletout]

@killakalle thanks - can you reproduce that for this URL: https://www.thecrag.com/5435016486 please?

[lordyavin]

I weren't asked to test but I gave the URL some shots. At the moment, right now, the loading time was okay for that URL.

I tried some other site items and it looks good at the moment. Just https://www.thecrag.com/en/climbing/south-africa/western-cape/area/4185353019 had some more delay.

I'm on WiFi

[lordyavin]

Just now https://www.thecrag.com/en/climbing/Spain took its time to load.

[scd]

Can you do a page reload and let me know if it is faster on the reload. Just in case it is a cold cache issue.

On Fri., 5 Nov. 2021, 4:31 am Kai, @.***> wrote:

Just now https://www.thecrag.com/en/climbing/Spain took its time to load.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/3976#issuecomment-961263662, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC3CQT4JZP7HJSWSUDIQKDUKK7NLANCNFSM5FR5QC4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[lordyavin]

Hi Simon I just loaded the spain node again on my computer with firefox and network analysis enabled (caches deactivated) response time was okay (reloaded several times). I browsed arbitrary pages on the site and it looks quite stable right now. I disabled pihole to check if it has an effect on the loading time but I couldn't see a difference.

Did you change anything on the backend?

[scd]

Nothing is changed in the back end.

On Sat., 6 Nov. 2021, 5:38 am Kai, @.***> wrote:

Hi Simon I just loaded the spain node again on my computer with firefox and network analysis enabled (caches deactivated) response time was okay (reloaded several times). I browsed arbitrary pages on the site and it looks quite stable right now. I disabled pihole to check if it has an effect on the loading time but I couldn't see a difference.

Did you change anything on the backend?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/3976#issuecomment-962128138, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC3CQTLBHHSFCJKNFSO6PDUKQQCHANCNFSM5FR5QC4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[lordyavin]

Okay that's weird. Any changes by the content delivery network? Are image. and static.thecrag.com single and individual instances or are the backed by a cloud?

[lordyavin]

Another report. I switched to the private mode of Firefox to add some news with another account and the server responses were shockingly slow again. Even the web developer tools think it is slow:

For non Germans the tooltip says: "Slow server response time (12.14s). Recommended response limit is 500ms.

[lordyavin]

A short video that shows me loading https://www.thecrag.com/de/klettern/germany/schwaebische-alb/donautal:

https://user-images.githubusercontent.com/1528540/140659171-2d19c36b-3ee4-4646-974e-4db21ecc5c10.mp4

Hope you get an impression how slow it is for me. Sometime it is even worse.

[killakalle]

Slow loading time on this node: 47 seconds https://www.thecrag.com/es/escalar/spain/valencia/gestalgar/area/2561079750

The screenshot is from reloading (browser refresh) - same bad loading time.

For me, this issue comes and goes. Sometimes the loading times are okay, sometimes quite bad.

[scd]

Thanks, that is good to know that reload does not speed things up. This means that it is not a cold cache.

The system is really doing a lot these days, and my working theory is that we are starting to get the occasional memory issue.

If you have got time, the next thing to look out for is how long this bad performance lasts for when it happens.

[lordyavin]

Just had the worst loading experience ever. Loading ended with a all blank browser content. Had to manually reload the page to get content. The reload was fast though.

[scd]

It sounds like a different problem. I just did a bit of browsing and the site was ok for me.

[lordyavin]

Another remark. Using the new log UI I recognize slow loading of the icons and initial forms content.

[matozoid]

Reporting that I too experience response times going from speedy to slow+errors and back.

[JonasR]

I can confirm this has been going on for at least half a year if not longer, in line with when this issue was first reported.

• I don't see any pattern regarding the affected sites. Loading them again afterwards usually works without any issues. In fact, when a response takes longer than a few seconds, I usually just click again and then everything completes in a reasonable time. In the cases where I do wait, response times of 20 seconds or more are not out of the ordinary.
• I'm fairly certain this isn't an issue with my internet connection, it's both wireless and wired, and all other sites don't have this problem.
• It's apparently independent of the device used. Not 100% sure I've had it on mobile (and there are too many other factors that might affect it which I cannot judge) but certainly on different laptops and desktop PCs.
• Browser is always Chrome in my case
• I just realized I never tried without uBlock origin being activated on the site, I deactivated it now and will report if that changes anything

Here's a recent example from just now (about 10 minutes ago at the time of writing). What exactly is the most useful way we can contribute (debug) information for this issue? Is a .har useful? It shouldn't be too hard to reproduce on my side, it really happens all the time.

Edit: By now I am sure this has nothing to do with uBlockOrigin. @scd How can we help?

[Wyko]

Just want to add that I consistently see this slow loading issue across multiple devices (mobile and PC) and different networks (various WiFis, cellular in two different countries). There are rare instances where it loads quickly (sub two seconds) but usually it takes at least 2-10 seconds to load a page. As a previous user mentioned, I also see this when using the new log form, as it sometimes shows the "Loading" popin for several seconds when I click on a UI element.

This issue really deserves some attention. I remember reading studies that showed that if a user needs to wait more than a very few seconds for a page to load, then they will quit and go somewhere else. This is going to severely impact how many people use this, which really sucks for a community-contribution resource!

[lordyavin]

Just got the following screen presented by Firefox on my mobile :

Tried to open a photo page : https://www.thecrag.com/photo/6905651334

[rouletout]

@lordyavin this is unrelated - the web server was down

[Arzorth]

Imported from #4147

Hi guys, it's me again.

I already told you privately when I first paid my supported donation, but I consider relevant mentioning it again, because I've seen the effects it has in real life and in the loss of revenue for the company/team it means.

Context

The web loads EXTREMELY low, it most of the times takes about 5-10 seconds (in some, even 30) to load one crag page, which is unacceptable for most of the potential users (not for me, I'm a patient person).

Example

I maintain pretty much alone the gym page of my local gym (which doesn't have any other ascent record system, so there is no competence at all for TheCrag, so it is a good opportunity to position as "gym ascent recording tool"), to log my own ascents and with the idea of providing my friends and the people climbing at the gym a method to log their ascents.

To advertise a little bit the page, I created a QR code and I printed some papers that I distributed around the gym.

After this, I've seen a lot of people scanning the QR code, waiting for the page to load for about 5-10 seconds and, with no result, locking the cellular, leaving it in a table and continuing climbing.

Consequences

This means that TheCrag has already lost many potential long term users just because it lost its window of opportunity (10 seconds).

This causes loss of potential users, which means less potential donors and ads clicks, which means less potential money for TheCrag, which means less resources to improve the page itself.

Imagine Facebook or Google taking 10 seconds to load a query, nobody would use them.

Suggestion

Invest money in making the site fast and user friendly, otherwise you are going to lose more and more users and it will become a nice and complete but unused database.

Regards,

José María

[Arzorth]

The web has always been quite slow but I didn't care too much until I saw with my own eyes people getting bored of waiting the web to be loaded, and discarding it as useful ascent-logging platform.

[lordyavin]

people getting bored of waiting the web to be loaded, and discarding it as useful ascent-logging platform

That is the worst that can happen... 😩

[JonasR]

None of this surprises me. I also can't be bothered to wait more than 3 seconds. Only difference is I know when this happens you have to keep hitting refresh until you get a request that doesn't hang forever and completes normally.

No idea, what's going on honestly. Last time we got an official answer appears to have been more than a year ago. Is this being worked on and it's just a hard problem or does no-one care and fancy UI changes are more important than actually getting any response in time at all?

*Edit: Don't get me wrong, it's not like I have to donate, the site is free and you can do whatever you want with it, team. I'm just surprised by the priorities being set. Any kind of feedback would be nice I guess.

[lordyavin]

Hey guys, I just experienced strange behaviour. No idea if it is related to the performance issue but may be it is a hint.

I opened the index entry for a route from link provided by an stream event. Then I wanted to go back to the previous page but nothing changed. Then I had a look at my browsers history and got that:

Either this is a firefox bug or the website redirected my browser more than 30 times to the same page. I'm sorry but at the moment I have no idea if that is something on my side. I tried to reproduce the issue but did not see that much history entries again.

Opening the route page from the stream event again created this:

I expect to have just one history entry, because I just clicked once and waited until the browser stopped indicating progress.

[scd]

There is another option, some javascript is pushing the state multiple times unnecessarily. I would be very interested if a browser was hitting our page several times to serve just once. So I had a look at the network traffic associated with the links and to me it looks like it is ok.

Just so you know, performance / scalability is super complex especially with an old system. There could be ten unrelated things all making a little bit of difference or could be a memory event happening while you are browsing. For example, about the time that this card was posted, we had a peculiar issue with loading kilterboard routes with thousands of routes in one node. Our underlying design was not sympathetic to this use case as we assumed a more human approach to areas with maybe only up to a couple of hundred routes per page.

Generally what I think is happening is that we have scaled to a size where we can be slow in busy times, and we are occasionally running out of memory. We have probably hit this point a little bit sooner than we expected because of background load of robots (ie SEO) being higher than we expected and additional database load because we have had to add complexity to queries for honouring privacy and sensitive areas.

Untangling all the performance issues will take time and will result in significantly higher server costs. However the main blocker is currently finding our internal devs time to work through the issues. It is not something we can just throw somebody on for a couple of hours and get a result.

[brendanheywood]

That particular page has a huge number of images loaded via the 3rd party hotel js which loads over 100 requests and totaling more that 3 meg or > 60% of the size of this page:

[lordyavin]

Thanks @brendanheywood for pointing that out. That day when I experienced the exploding browse history, I also discovered the new sidebar advertisements about accommodations nearby. In principle it might be useful to have that shortcut, but most of the time I don't care. Sadly this takes a lot space which was populated with crag photos previously. That this "feature" was introduced without any notice and that it increases the requests and downloads is really annoying.

What the hack? We are aware of performance issues since a while, right? Now we got another feature we did not request and which decreases performance again?

I always loved that theCrag showed some static advertising banners only. Actually was this something I always pointed out to friends when talking about the service. This times seems gone. Please, please be more transparent about the necessary funds and actual costs. Maybe the community is going to appreciate that with more donations. Please get inspired by Wikipedia which does not serve advertisements at all.

[lordyavin]

@scd thanks for the response. I understand that solving this issue may be a deep shit dive eventually and hard to debug.

[DaneEvans]

The new tick interface has been a massive regression in this, I waited ~15 seconds for it to load multiple times yesterday trying to log at Araps, it's at the borderline unusable stage.

[brendanheywood]

In my experience the biggest bottle neck when loading the new ticking interface is blocking waiting on the previous ticking data for this route to be loaded to this api endpoint eg:

https://www.thecrag.com/api/node/id/1234567/mysummary?cookieAuth=1

1) I think this call could be completely eliminated, the page you are on already knows that you have ticked something before. I haven't tried to reverse engineer it but my guess is that the only reason is needs this call is to look up the previous quality rating you gave it before. A) This data could already be loaded in the main index page as part of the tick data for your previous ticks and re-use so you don't need the extra ajax call, and also B) It could be made completely redundant - I don't think it needs to be set as the default at all. I would regularly give a different ascent of the same route different ratings, I am rating that ascent not the route. If it was dirty or wet or whatever that affects my subjective experience on the day. If I tick it multiple times only my latest rating matters, and if I don't rate it then that's also fine. I think just like the tick type for each attempt this should be left with no default for each ascent.

It would be a pretty small change with a potentially large impact on the overall ticking experience.

A few other low hanging fruit which would also make a difference to the ticking ux:

2) I like to tick the routes in the order I climbed them, potentially repeating the same route in a session, so I tick them one at a time. The modal which pops up after each ticking showing the cpr to me adds no value and I ignore it and it slows me down. 3) When I tick I scroll up and down, find the route, the ticking modal pops up, and in the background the scroll state jumps around so when I am finished I'm not where I was. It appears to always scroll up about half a page.

[rouletout]

We are aware of performance issues as you probably read now in several forums and dashboard messages. We are currently experiencing unusual loads which are one of the main reasons for the poor performance in the last days. We are actively working on making the performance of the site better but this is a slow and difficult process. As this Git-Issue is a wide collection of different things, many of them already addressed we are closing it. Please open dedicated ones if you see anything concrete.

[lordyavin]

So the check boxes of the original issue description are done? Really? I can't confirm that the overall website performance is at the level I would expect it to be. If the comments in this issue don't fit then you are free to spawn them into new issues. But that is not a reason to close an issue. Additionally you closed it as completed. That is simply not the case.

I have the impression you are not interested if the issue is fixed for the reporter (me) if you don't ask for feedback.

[rouletout]

I think my comment explains the current status and the reason for closing.

[DaneEvans]

How about you let us know what all of those other issues are then, and we'll go fill those out?

This is at least the 5th active issue that I've seen you close as completed, and I fully expect it too to be ignored while you push ahead with features.

You are very close to losing my support with this behaviour.

So, we want issues for :

• The history explosion
• performance of the new ticking modal Any others?

On Fri, 10 Feb 2023, 8:07 am rouletout, @.***> wrote:

Closed #3976 https://github.com/theCrag/website/issues/3976 as completed.

— Reply to this email directly, view it on GitHub https://github.com/theCrag/website/issues/3976#event-8483816663, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFIRN4K7E5UOKAZWTDMO4E3WWVMAHANCNFSM5FR5QC4Q . You are receiving this because you commented.Message ID: @.***>

[nicHoch]

@DaneEvans is the The history explosion still an issue for you? this should be fixed sice a month can you please confirm (maybe with a screenshot) that it is still an issue?

[brendanheywood]

I've split off the specific ajax issue with the ticking modal into here:

https://github.com/theCrag/website/issues/4173

[lordyavin]

I'm sorry but I have to reopen this again. Website is still not responsive enough.

[Arzorth]

I completely agree, there were some days in which it looked like it was faster, but not anymore, it has the same poor performance as more than one year ago.

Development team, please invest resources on this topic, otherwise the web is gonna be abandoned.

Regards

[JonasR]

No need to scream ;) But I agree, it got a bit better at some point, and now is as bad as it used to be. I referenced this issue again (same as last year...) when refreshing my supporter status just now.

[nsbat123]

theCrag-website has been hopelessly slow to load pages since I started using it early January. So many good functions and promise are wasted due to the low responsiveness of the website. This bottleneck is my main reason for having abandoned the page for 8a.nu which is in many ways rudimentary to theCrag.

I agree with JonasR that it should be invested more resources to amend the issue or people won't use theCrag.

[lordyavin]

It's so annoying. Just got a timeout.

[lordyavin]

yet not fixed for me