Slow loading time with microsoft surface

hi

we have a client that has a surface tablet, and they get really long wait times when loading.

every other device we have the same load times and good times. but the surface is 3 times as long roughly.

was wondering if anyone has had the same issue that could shed some light on why.

the problem is we dont have one to do any testing or diagnostics, and they are to far away and too busy.

Can you ask for a video of the preloader bar when they are loading. For example, is it all orange and takes ages there? Or does it fill slowly?

will ask for a video

no video yet sorry, but it is that the bar fills really slow

That implies a very large project (lots of files and data to download), a slow network speed and/or they far from where the build is hosted.

If it’s only that device that’s having trouble, it could be the network speed. It be worth having them do a speed test on the device.

Also, how large is your preload download?

its only that type of device that has this issue, they did a speed test and had a good result
the project is 23mb when i look at the published list, im not sure if thats the pre load that you mean, we have set the textures to not pre load.

How much data is downloaded before the first render frame (ie how much data is downloaded during the orange bar loader)

Have they tried other browsers on the device?

What download speed did they get?

Can you share a build of the project with me over a private message? Maybe I can spot something there?

how can i check how much data is downloaded before first render frame please?

i sent a message with a link to the project

Hi @Will_Viewtek,

You can open the browser dev tools and on the Network tab you will see a list of resources getting downloaded while the app loads.

At the bottom you can see the total file size of the resources.

is this what you mean?


Yes, exactly, so from what I see you have about 50MB of data (edit: as yaustar pointed out, it’s 21MB when compressed and downloaded), which can be a lot in slower connections.

But what makes it quite slow is the huge number of assets that are preloading, that translates in about 600 http requests. Browsers can download those resources simultaneously only in small batches of 6-7 requests, that means it’s going to take a while to download all of them.

I’d suggest if you are able to lower the number of unique assets, eg sprites/2D graphics can be added to the same sprite atlas.

And consider downloading some assets at a later time, when they are needed in scene, by setting their preload flag to false.

1 Like

thanks for explaining about the pre load and how to see it.

we have all textures and materials set to not pre load (except UI), but we have not set any meshes to not pre load.
but pretty much all of them are in the first scene.
do you think that setting the meshes as well to not pre load (or a selection of the smaller assets) would help?

Well, it may help, but if all of them are being required in frame one then it won’t make any difference.

1 Like

ah ok, makes sense XD

Looking at the published build link, 21 MB is downloaded during the preload step with 540 ish requests which is a lot as Leonidas has mentioned.

Judging from the asset names, you may want to consider loading the larger pieces of geometry first (building, skybox) and when the user is actually in the scene and can see the building, load all the interior assets (models and textures) gradually.

This would lead into models ‘popping’ into the scene so you may want to consider using some placeholder (eg a cube/sphere) to show that things are still being loaded.

I’m also wondering if merging some of the models together so that it is a single model asset would be better than having 100 separate model assets for the outside view. That would greatly reduce the number of HTTP requests for the build for example.

1 Like

ok, thankyou for the advice.

we will have a go at reducing the http requests by using pre load and mergin meshes.

will let you know how it goes

I would also look at loading as little as you can at the preload step. Usually developers aim for around 4MB and have a secondary loading screen once there is something interactive for the users to do.

ok sounds like a good idea, i will float that idea with the rest of us to see if they like it too.