What could be the problem

[LoyceV]

I want to ask if that also applies to a prone node

Yes. A pruned node writes the same amount of data and uses the same amount of RAM.

[nc50lc]

-snip-

I think I understand your point but I want to ask if that also applies to a pruned node

Yes, and not only the advantage of higher dbcache, the available disk space of storing the complete UTXO-set is also required.
This is why even if you set the lowest possible prune setting, your node will still require about 13GiB of free space, mostly for the UTXO-set which may go higher or lower ("chainstate" directory).

As for major contributor to disk I/O, even if the node is in prune mode, it will also write all of the blocks to the disk as it downloads them from its peers, it will not skip a block.
The only difference is it will eventually delete the oldest verified blocks when it's near the set prune size.
So, that time-consuming disk writes and verification are also applicable to it, so as the config optimizations.

[LoyceV]

As for major contributor to disk I/O, even if the node is in prune mode, it will also write all of the blocks to the disk as it downloads them from its peers, it will not skip a block.
The only difference is it will eventually delete the oldest verified blocks when it's near the set prune size.
So, that time-consuming disk writes and verification are also applicable to it, so as the config optimizations.

I'd like to add a side note to this: with low RAM, writing blocks is insignificant compared to writing chainstate. After the IBD, it adds only 10 MB per hour. And that's why Bitcoin Core works totally fine with the blocks directory on a slow HDD.

[YellowSwap]

How come no one is talking about page file?
If OP increases the page file of his PC the syncing will become snappier than before.

Why?

Increasing your page file can significantly improve system performance by acting as Virtual Memory or RAM.
It provides necessary overflow capacity for memory intense applications.

I have toyed with this feature in the past, not once or twice then things started working better than before especially when it's syncing related issue.

A tutorial video here

https://youtu.be/tSehQBqKjBQ?si=nvlho1V0eZo2HlcV

[LoyceV]

Get enough RAM (16 GB is the minimum for a smooth sync) and set dbcache to a high enough value (but not all your RAM).

Allow me to update this: I'm currently testing a full IBD on Bitcoin Core 26.1 on a system with 16 GB RAM. I set 12 GB dbcache, and it took about 24 hours to go from 75 to 85% progress. It took just as long to go from 0 to 75%. The most amazing part: bitcoind only uses 4.7% RAM! It's just not using dbcache as I expected. This may be because I'm using an older version, I haven't tested an upgrade yet. I'm curious to see how much this improved in later versions.

If OP increases the page file of his PC the syncing will become snappier than before.

That's very unlikely.

Increasing your page file can significantly improve system performance by acting as Virtual Memory or RAM.
It provides necessary overflow capacity for memory intense applications.

All it can do is swap away your unused applications. You'd be better off just closing them.
Bitcoin Core needs to access it's large chainstate directory many times for each block. If it can't fit all of it in dbcache, it'll cause additional read and write actions on your disk. Moving those read and write actions to a swap file does not make it faster.

things started working better than before especially when it's syncing related issue.

Please elaborate on what issue you had syncing Bitcoin Core.

[MarryWithBTC]

If OP increases the page file of his PC the syncing will become snappier than before.

That's very unlikely.

Very much unlikely, unless in a situation he is already low on RAM, then the improvement might have come from stablizing memory usage, such as preventing heavy swapping just as you mentioned above.

I have toyed with this feature in the past, not once or twice then things started working better than before especially when it's syncing related issue.

May I know if the twice or more you tried and it worked was on one system or different computers?
if it's with same system, it could be a specific bottleneck on the system, likely low RAM or other heavy apps were open.

[nc50lc]

How come no one is talking about page file?

Because most OS already set it to a suitable default settings depending on the hardware, not disabled at all.

Plus, the slowest part of syncing is mostly script verification and disk I/O.
So the goal is to keep other processes to use the disk as much as possible, including swap file.
This is why most people recommended larger RAM size and higher database cache settings.

I have toyed with this feature in the past, not once or twice then things started working better than before especially when it's syncing related issue.

Probably the system was already heavily used by other processes that Bitcoin Core was struggling to sync, so it's slower than average.
And by doing so freed some memory that made it work at its "normal" pace.