Help required to analyse why site is very slow to use

I have a big problem at the moment and I don’t know which way to turn. This is an extract from an email my client sent to me which basically states the problem…

“My biggest worry at the moment is the speed on the site. Everything seems very slow. It’s not just the speed that the contacts load, it’s every command. It’s almost unusable.”

He goes on to say that if things don’t improve significantly then he will pull the plug on the whole project and look to recover monies that he has already paid to me. So I am looking for some help from this community.

I know it can be very difficult to point the finger at any one thing and say that that will solve everything, on the other-hand it can also be very easy to say simplify this, that and the other and it will all add up to an improved state. None of that really helps.

I know and understand a bit about Chrome’s DevTools but I don’t know anything about how to analyse speed.

I also know the issues could be related to

  • The hosting service, processors, shared facilities etc (this is on the client’s VPS)
  • Browser (Customer uses Chrome)
  • Processing power on the customer’s computer
  • Efficiency of SQL queries
  • Efficiency of coding in general etc

Is there anyone out there that can help me get to the bottom of this?
Any help is appreciated.

Hi Neil. Can you give some more details? A link to the site, some background on how it’s developed (I’m assuming all done with Wappler but what server model, etc.?) and I’ll see if I can find anything obvious. Feel free to PM me if you’d rather.

Have you another location you can upload the site to and test? I can set you up on one of our boxes temporarily if needed? UK dedicated box (1gps bandwidth, 6 core Xeon with 768gb memory).

Inherently shared servers have their own issues. We had a user running a CRON job every minute and it caused aggravation for over thirty other sites hosted on the server. We went through everything for days to figure this out. In the end we used the process manager via SSH to see what draws were being made on the server and by which users. We were close to migrating everyone to a second server while we rebuilt the problem server. For a few days was really tense to say the least.

Maybe just upload some test version / test page where we can see what’s slow?

Feel free to dive in and have a play, login details at the bottom.

Suggest taking a look at Contacts and then adding your contact details via 1
and then adding a vehicle report via 2

Start a report here

Click “Accident Damage”
Then type QDOS, and select it
Just fill things in as best you can

The data is ‘almost’ live data but don’t worry about that, the site isn’t launched yet and I have it backed up.

If you are unsure of things then feel free to come back to me.
User login
User password 123456

The host Operating System Centos 7 x86_64

Seems to run OK here. And I’m going through a VPN in Portugal. Everything loaded in reasonable time. Added vehicle RUD 32P. PDF generated quickly…

1 Like

Hi Neil,

Another tester in the UK here. Briefly looking everything appears to load fine at an acceptable speed. Faster than a lot of other web apps I use on a regular basis. A little vid…

I’m running Chrome (on a Mac) but bear in mind I have a dedicate line (100 up/down) which may be slightly biased. I know some internet speeds in the UK are still sub 10mbps.

PDF’s also generated in an acceptable time. Do you think your client might be using this as an “excuse” to avoid paying up? Head that one before…

1 Like

Some things I’ve noticed.

You are downloading 1MB of data when you load the contacts. Why not use a paged query instead of downloading so much info?

Contact page is putting a lot of pressure on my CPU. I’m assuming your are pushing a lot of processing to the client side also because my laptop is struggling there.

And after loading the contacts navigating through the rest of the app seems clunky.

I’m using a macbook pro 2015 with maxed out specs. i7 2,8Ghz, 16GB RAM and 1TB SSD

I don’t think the problem is on the server. It’s the amount of things you are pushing to the client. So if they have low-end computers they will struggle.


Hi Neil.

I tend to use Lighthouse to see where my site needs fine tuning.

As you can see, the page gets a definite fail for performance.

Work through the list and rectify those resources that are easily rectified. Like deferring all JS files with the exception of App Connect and jQuery.

1 Like

As @JonL said, your contacts server action is quite huge. And if the data on the page relies on it, it will be slow.
See how many seconds it requires to download the data from the server:

You should consider using a paged query - probably you don’t want to display and process 3k records at once on the page.


Hi All,

Thank you very much for spending some of your valuable time looking at this site for me. I take on board all your comments and will be making some changes.

I had already thought about paged query for the Contacts so I will definitely do that.

@ben, not quite sure what you mean by deferring, can you elaborate? And I will look deeper in to Lighthouse :+1:

@max_gb, no, I am confident this is not what is in his head. I have known him for 30 odd years and so know him well. He has old/slow machines but he constantly compares to Amazon, eBay, Just Eat etc all the big boys. He says why do their sites run fast and his doesn’t. That’s what I am up against.

<script src="" integrity="sha256-CutOzxCRucUsn6C6TcEYsauvvYilEniTXldPa6/wu0k=" crossorigin="anonymous"></script>
<link rel="stylesheet" href="" />
<script src=""></script>
<script src="[../dmxAppConnect/dmxSummernote/dmxSummernote.js](" defer=""></script>
<script src="[../dmxAppConnect/dmxSummernoteFileUpload/summernote-upload.js](" defer=""></script>

As you can see from the above, the last two links have defer='' added. Unlike the CDN versions.

I now also see that Summernote is called twice, once locally and once through the CDN

OK, thanks for pointing that out, I hadn’t noticed before. So what does it do exactly? Or not do? And should I ensure this is applied to all JS files (except those mentioned)?

It’s not, both of these are required and they are two different files.

<script src="" defer=""></script>
<script src="dmxAppConnect/dmxSummernote/dmxSummernote.js" defer=""></script>

Apart from the contacts page which is easily fixed, I wouldn’t have thought performance was a problem. I’m viewing the site using an M1 Mac mini and a good, but pretty standard, BT connection.

There’s a very impressive array of features. Presumably this is what your customer wants, rather than a simple, very fast interface. I wouldn’t have thought it was fair to compare the site with the likes of Amazon or eBay. For sites like these, performance is critical, almost above anything else. Obviously they deal with a massive amount of data and have correspondingly massive resources to deliver it. The end user is not presented with a UI with a huge number of features. I doubt if the UI at the other end is quite so fast.

1 Like

I agree with your valid comments Tom but it’s making him realise that. I will change the Contacts page to be a paged query and do a few other little changes and see what he says.

Good luck. Perhaps if the client explains if there are areas which have a negative impact on users’ work, you could focus on those. I didn’t come across anything which would have any such impact, but obviously I didn’t have an in-depth look.

1 Like

Just a quick observation:
The contacts query returns over 2000 records
but the platform says 509 companies found:

That’s without any filters applied. Is there more you can filter in the query on the server that the page doesn’t need?

I am also getting some files missing that also impacts on load times:

Invoke-WebRequest -Uri "" -Headers @{
  "sec-ch-ua"="`"Chromium`";v=`"88`", `"Google Chrome`";v=`"88`", `";Not A Brand`";v=`"99`""
  "User-Agent"="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36"
  "Accept-Encoding"="gzip, deflate, br"
  "Cookie"="PHPSESSID=nm36bbt3okedh4vqsm5c6thtb6; login_sec=izozC3g0zFEiIoPQgFISHpSIvRfL5QxlkSQmUcB0d1yHj3mjHmfdnhv2zoFY5pX9SLLL6j1HWucddKF%2BGnS96w%3D%3D"

Hey @UKRiggers

I’ve not had a chance to play with your app, but I expect we are in a similar place in terms of size of app and performance. I know I’m skirting the edges of when the user’s machine starts to slow down at times.

I’d love to see some clear documentation on how to use Wappler to create speed efficient sites with good examples.

The simple thing I am learning is to push as much work onto the server as possible. In particular with regard to the data you request to display.

For example, I have situations where I am displaying event attendees and messages they have been sent. So it seemed sensible to go and fetch the attendees from the database, go and fetch the messages, and then use a repeat and .where() to create the table. But the repeat and .where() use a lot of the client’s resources and end up really slowing things down. So I’m moving to one database call that gets everything in one go and no .where() in the display process. It took me time to learn about all the types of join in a database query, but now I understand that then I think I have the tools to move forwards.

I’m also re-designing some of my GUI to be less based on big tables showing lots of data, and making more of the information available via a modal if someone wants to see the details.

Variables inside repeats can get really slow.

Conditional regions rather than show/hide can speed things up as they release the local resources they are using when no longer displayed. The down side is each time you go back to that region it can be slower to re-draw the page.

Look carefully at what you read in as an array. When you get your complete list of contacts, just get the info you need to display and search through them, e.g. name, email, id. Leave address, notes and all that other detailed info for when you open one specific contact. I just checked my contacts server connect and it is about 250 bytes per contact, so plenty of room for a good few 1000 without overloading things I think.

There’s probably lots more people can contribute to this…

Would love to see as many tip and tricks grouped together somewhere as possible so we can all avoid these issues in the future!

Best wishes,