Game lags in the first few seconds when first started, but not anymore when same scene is reloaded

I’ve noticed a bit of lag whenever I first load my WebGL build. Now, the strange thing is that when I restart the same scene, meaning I do all the same processes than the first time, the lag is gone.

Is there anything that Unity itself does when a game is first started that it doesn’t to when (re)starting a scene? Any idea how I could avoid / optimize it?

Regards …

Depending on the browser, code/data are cached so the second time it’s faster because you don’t need to re-download and/or re-compile code.

1 Like

Hi Marco,

when reload level … no when reload page web.

When starting always during the first 10 seconds there a lag, no more than ± 10 frames per second … after of 10 seconds frames is OK going to 60 frames per second … and when reload level (sceneManager.LoadScene) no lag for the first 10 seconds …

One ̶h̶a̶c̶k̶ technique I’ve used to address this is to wait until things settle down before letting my scene “start”.

To do this I have a method that essentially does:

    public static Coroutine waitUntilStable(this MonoBehaviour b, float maxWait, Action action)
    {
        return b.StartCoroutine(_waitUntilStable(action, maxWait));
    }


    private static IEnumerator _waitUntilStable(Action action, float maxWait)
    {
        float startTime = Time.time;
        //
        // Let's aim for 75% of the target frame rate
        //
        float targetFrameTime = 1 / (Application.targetFrameRate * 0.75f);

        int consecutiveGoodFrames = 0;

        //
        // Wait for enough good consecutive frames or the max wait.
        //
        while ((Time.time - startTime < maxWait) && (consecutiveGoodFrames < 20))
        {
            yield return null;

            if (Time.deltaTime <= targetFrameTime)
            {
                ++consecutiveGoodFrames;
            }
            else
            {
                consecutiveGoodFrames = 0;
            }
        }
    
        action();
    }

Then I call it something like:

void Start()
{
  this.waitUntilStable(()=>{ stableStart();});
}

It’s a nasty hideous hack and is likely to fail in some scenarios (hence the max wait time), but it’s worked around the issue for me in some cases.

1 Like

Hi again Marco …

… i built a project empty … only camera and a UI text … showing frames per seconds … when starting does not reach 60fps immediately … but when you press the restart button (and reload scene) the 60 frames are instantaneous …

… try here please https://gstudios.pro/testStart/index.html

Thanks, there must be some better method …

… but your contribution helps me a lot, it gives me ideas.

1 Like

Another hacky option is to first load into an empty scene with an image or video that imitates the splash screen and then load the real scene async.

I’ve found that this can overcome the initial frame issues and doesn’t add much loading time.

I’ve recently done this for different reasons but I noted that it certainly helps. My objective was to load an empty scene, play a full screen video (as a fancy loading screen) while my real scene loads.

This worked out really well, it loads the first scene really quickly and then shows the user something far better than the splash screen or black screen or what ever is typically showing and I also don’t get the initial poor FPS performance at startup…

It’s a very simple thing to test, you may be surprised how well it works.

1 Like

Something similar was thinking … very thankful … thanks @larku

PD: researching from the chrome profiler to find out exactly what happens … lag appears even with simple project clean without code in Awake, Start … functions

1 Like

I’ve had this problem before, especially in lower end devices like chromebooks. I believe it is the browser JIT compiler trying to optimize your code. Try doing a webassembly build and you shouldn’t have this issue.

1 Like

Thanks, i try

True, thanks :wink:

I had deactivated data caching because it does not work in versions 5.6 or superior.

I migrate to 5.5 to enable data caching … and with data caching the issue is solved.

The issue appears only if it is not enabled data caching.

  • with brownser cache enabled but no data caching enabled … the problem persists.