I ran into the same issue and discovered that it has nothing to do with incognito / private tabs, rather it was a matter of performance and timing.
The plugin uses two separate triggers for inserting the preloader div into the page and then fading it out after the configured delay. Sometimes the fade was being set up before the preloader div existed, thus the preloader never got to fade out and instead stayed on top of the fully loaded page.
To fix this, I removed the window.addEventListener() call that was setting up the fade at the end of wp-smart-preloader/assets/js/wsp-main-script.js and moved it up to line 58 immediately below the code that loads the loading animation into the preloader div:
if( "home" == flag ){
jQuery('body.home:not(".elementor-editor-active") .smart-page-loader').prepend(block);
}else {
// all pages
jQuery('.smart-page-loader').prepend(block);
}
/* moved here from the window.addEventListener() call at the end of the file */
fade_away();
function fade_away(){
jQuery('.smart-page-loader').delay(delay).fadeOut(duration);
jQuery('body:not(".elementor-editor-active")').removeClass('wp-smart-body');
}
That ensures that the preloader div has been inserted into the page and filled in with the loading animation before the fadeout timer begins. Hopefully the author will test and incorporate this fix into the next release.
