Well, if multiple different users have the same issue, it pretty much definitively rules out network issues.
Also, though, I noticed that you were the first player in the server. Could the server still be loading the map in, then going through the replication process. Maybe try with multiple players, one who is loaded in to see?
The player list doesn’t implicitly display all players. Players are still instances that need to be replicated.
Replication is localised, not globalised. Adding more players to a test wouldn’t change the results. They will still go through the same replication process that I do. The server has implicit access to the map and will always have it readily available. The server needs to replicate the map to the client so the client can render and display it. This is also why usage of WaitForChild is encouraged on the client for Workspace interaction but not necessarily for the server (unless you’re unsure if a modifiable instance will change at run time).
No, but the server still has to load the map, doesn’t it?
You can see it doing that when you open a testing server and the map has to load.
Surely it can’t replicate items until they were actually loaded at server start.
This is the server replicating the Workspace to the client, not the server loading in the map. The client can’t see the server’s copy of the map, but changes that the server makes to its copy of the map are replicated to the client.
You can see the server loading the map when the server window opens.
And, because you seemed to have started a server, could it not be that the server itself is still loading the assets?
I’m not quite sure what you mean by this. The Workspace is available to servers when I initiate servers in Studio mode. The server already has access to the geometry data. The Workspace is included in the DataModel snapshot that’s replicated to the client. There’s a reason why WaitForChild isn’t explicitly necessary on the server aside from objects that have potential to not exist.
Doesn’t work like that. Whether I start the server or not doesn’t have any bearing on this action. The reason I’m stuck in the sky is because the server is still trying to replicate the DataModel snapshot to my client, which said replication is taking longer than expected.
See this chat on replication:
(by Anaminus)
I just mean, when I open a testing server the server does take some time itself to load in the game.
When the game opens, not everything loads imidiately for the server. It still has to load them.
Also, in the rare cases that the client replicator loads before the server has finished loading in assets, I do end up in the sky for a bit before I load in.
What window are you using? The server has access to the map immediately, as do the scripts. There is a reason why using dot syntax to index DataModel children in a server script doesn’t throw an error and why it’s almost enforced that you do so via a LocalScript.
Would never happen. If the server doesn’t have anything to replicate, the client wouldn’t receive anything. Client-only services aren’t an exception either, because a snapshot still needs to be queued and replicated (as shown in the above).
Isn’t that exactly what is happening though? The server doesn’t have anything to replicate yet so you end up with an empty skybox?
My debug windows beg to differ heavily. They’re still receiving data, nothing is idle at this point. Plus there is still a game to be replicated, evident by what’s shown after you actually load in.
Before:
After:
Ok, sorry I was wrong. I thought that some content could still be downloading server side and that could slow down replication.
But after a deeper look at some information about replication, it turns out that the server doesn’t actually download content at all, it just stores the asset ID and leaves the rest to the client.
Sorry for clogging up the thread with this.
Wait a second. In the first picture, why is your ping on 0.00 ms? Surely there must be some delay between you and the server?
Is this normal for when replication is happening or could this be suspicious?
Right. The server isn’t the one that displays the map - it already has access to the geometry data in a snapshot when the server loads in. The actual map that you see when you play a game is the client’s copy of the map that’s replicated from the DataModel snapshot that the server sends.
I wasn’t experiencing any lag, but it seems that I was receiving large amounts of data that weren’t being processed. You can see the massive difference between the incoming kilobytes and packets before replication and after. I’m not too sure ping is a relevant statistic.
Yeah, you’re right about ping. I was just marvelling for a second at your internet speed, with 0.00 ms ping 
Hey I saw this and I instantly stated a question that I profind very important to know.
When you upload textures, the textures usually end up in the Asset Manager:
I ended up asking myself:
Does this cause slower loading times?
If you re-use the texture multiple times, would that slow the loading time?
Textures that are far away, do those load?
I’d be happy for a reply, even though this is 3 years late 
The asset manager is purely for Studio development so it has no bearing on the performance of your experience in a live session. As for reusing the texture, the texture itself only needs to be stored in memory once so you might instead see rises, possibly trivial, in graphics rendering if the texture is applied to multiple places.
I don’t have any information about rendering on far textures since I don’t typically pay attention to that part when developing. I’ve been doing more code work than physical appearances for a while so haven’t had the chance to observe that behaviour yet.
I see, thanks a lot for your reply 
It helps me understand a little more about performance, hopefully others too even though this topic can be considered old
i have the same problem D:
but im trying to fix it, ill let you know if i do
I think streaming mode option in the Workspace property can improve load time if you edit it a bit.
what if one uses task.spawn() for loading initial components and doing pre-game calculations instead?
