Game loading has 3 primary phases:

1. Mod Loader Initialization
2. Minecraft Boostrap (Vanilla setup + Mod initialization)
3. Resource Reload (Resource loading + Mod loading)

Mod Loader Initialization

In this phase, Forge Mod Loader will initialize the necessary services, such as accesstransformer, coremod, mixins, and this mod. During this phase, there will be a primary scanning of mod files, but mods without services will not be loaded. This mod breaks this phase into 5 stages:

• Services Initializing: It's the first stage and should be fast.
• Services Loading: Some mod services might do work here, causing long load time.
• Mod Scanning: If you don't have other service mods, this will be the first stage you see
• Launch Plugin Working: In this stage, mod code will be scanned to collect basic information.
• Transformer Class Loader Working: In this stage, accesstransformers, coremods, and mixins will start loading. It might take a long time if you have a lot of mixins or coremods.

Game Bootstrap

In this phase, minecraft and mod code starts loading. It's split into 17 stages due to the fact that any of those stages can be significantly altered by mixins. Having the detailed breakdown available will help to identify cause of slow loading.

• Client Early Initialization: In this stage, no game content code is loaded. Load time here is primarily affected by mixins.
• Vanilla Bootstrap Start: In this stage, vanilla game content (block, items) is loaded. Should take around 1 seconds. If you see longer time here, it could be fabric mods.
• Loading User / Options: In this stage, minecraft loads user profile and client options. It should be fast, many classes are loaded here and thus more mixins are triggered. It should be primarily mixin loading.
• Minecraft Client Initialization: In this stage, minecraft initializes its client infrastructure. Same as the phase above, it's fast in vanilla but since it loads many classes, it will trigger more mixins loading.
• Loading Languages: Here the game loads minecraft and forge language file. Should be within 20ms.
• Constructing Mods: The beginning of actual mod initialization. In this stage, mods are being constructed. The exact breakdown per mod for the actual mod loading process will be available later. Since mods are loaded in parallel, the actual duration of mod loading (actual time) will be shorter than profiled mod loading time per mod (thread time).
• Creating Registries: In this stage mods that have custom registries will initialize them.
• Gathering Object Holders: In this stage, mods register their object holders. It's part of registration process.
• Injecting Capabilities: In this stage, mods that defines Capabilities will have them initialized.
• Loading Registries: In this stage, mods will register their game objects to registries. It is the last step of mod initialization. 
• Gather Modded Resource Packs: In this stage, mods add optional (default enabled or not) resource packs to the game. Some mods might do work here.
• Gather Tasks: In this stage, Minecraft and mods register their tasks (reload listeners) to the reload manager. It's usually fast, but you might find it being slow if mods are actually loading instead of registering loaders here. (It's bad coding)
• Setup GUI: Setup the vanilla GUI components. Should be fast.
• Dispatch Client Events: In this stage, there are a lot of modded events being dispatched to mods.
• Vanilla Client Setup: Misc vanilla client setup, such as narrator.
• Initializing Tasks: In this step, minecraft starts to initialize tasks (reload listeners). If you find this step slow, that means some mods are doing work here instead of the actual task process. (It's bad coding)
• Setup Loading Screen: Initialze the "MOJANG" text in loading screen. Last step of Game bootstrap.

Resource Reload

In this phase, tasks are being collected and executed in parallel. There will be a detailed profile of how long does each of the tasks take. The total time of all tasks might be shorter than the reload process, and the ratio will be your thread utilization rate. If you have a utilization rate of 400%, that means 4 CPUs are running in parallel nonstop to process all the tasks so that you spend 30 seconds to finish tasks that takes 120 second to run if it's run by 1 CPU.

Notably, the slowest task here should be ModelManager. ModelManager is responsible for loading all the block models in the game, and this process is broken down into 10 stages.

• Reading jsons: Model loader reads json model files from vanilla, mods, and resource packs.
• Parsing jsons: Model loader parse json files into UnbakedModel
• Adding modded special models: Mods adding their own special models
• Resolving hierarchy: UnbakedModel is being processed to have parents assigned
• Stitching Textures: Merge all textures together into one big texture. This happens in parallel as reading json. If you find this stage taking no time, it means that it finishes earlier than the previous 4 stages.
• Baking models: In this stage, models have texture information attached, forming BakedModel
• Mods altering models: Mods can alter BakedModels here.
• Assigning models to block: In this stage, models are being assigned to block states. It could be slow if you have a lot of block states.
• Waiting for barrier: Waiting for other tasks to complete.
• Uploading stitch: Upload stitched texture to GPU. Some mods might be doing work here.

This section shows the duration of of phase 1 (mod launcher initialization) and phase 2 (minecraft bootstrap) stages. There are 22 stages in total here. Usually the slow stages should be:

• Transformer Class Loader Working (mixin)
• Constructing Mods (mod initial code)
• Loading Registries (mod registering game content objects to registry)

Example format:

Game takes <xxx> seconds to bootstrap
 <Stage>: <xxx> ms
...

This section displays the total execution time to complete all tasks, and individual task execution time. General tasks will be displayed first, and then mod-specific tasks. In detailed view, there will be 2 numbers displayed for each task: main thread time and total thread time. Main thread time refers to time taken for tasks to be executed in the main thread, for things than cannot be run in parallel, such as modifying data of game objects. Total thread time refers to the total time this task occupies the CPU for. It could be longer than total execution time if this task is being broken into multiple pieces executed by multiple CPUs at the same time.

Example format:

Reload Manager takes <xxx> seconds, loading <xxx> tasks
Tasks are processed in parallel using multiple threads.
- <Task>: <main thread time> / <total time>
...
Misc <xxx> Tasks: <xxx> ms / <xxx> ms
Model Analyzer: <xxx> ms / <xxx> ms
Main thread utilization: xx%
Off thread utilization: xx%
Idle time: <xxx> ms

Misc Tasks refers to tasks that takes very short time to run. It will be too much of a bloat to display all of them, so I display only a sum of all those tasks here.

Model Analyzer is a task this mod adds to analyze the origin of models. I will help to show which mod is adding a lot of models to load if you find it taking too long. This task should be taking <10% of ModelManager's time.

Main thread utilization: how much the main thread is being used for loading tasks. If you find it being high, that means that there are mods executing slow tasks in main thread, which should not happen.

Off thread utilization: effectively how many CPUs are being used to execute all the tasks

Idle time: time where none of the tasks are running. Could be caused by mods assigning wrong executor to run their tasks, causing this mod not able to tell who is running.

This sections display the time for each mod to initialize and load. Please note that this only takes account for mod construction and mod events. Mixins and Fabric mods are not accounted for here. 

Mods taking longer than 0.1 seconds will be listed, and mods taking longer than 1 second will have details listed as well. The detail will include construction time (which is usually the longest) and mod event time (mods usually do work during each of the events so that they happen at the right time).

Example format:

Mods use <xxx> seconds to initialize
(Explanations)
Mods use <xxx> seconds to load
Mod init takes <xxx> seconds CPU time. Thread utilization: xx%
- <modid>: <xxx> ms
  | - <process>: <xxx> ms
- <modid>: <xxx> ms
Misc <xxx> mods: <xxx> ms

This section shows the time breakdown of the 10 model manager loading stages. 

Stage "Adding modded special models" and "Mods altering models" is usually very fast, but could potentially be slow if mods are havily adding modiying block models.

Example Format:

Model Load Time per Stage:
- <Stage>: <xxx> ms
Found <xxx> packs
Loaded <xxx> model files with total size of <xxx> KB
Baked <xxx> models
- <mod jar or resource pack zip>: <xxx> KB
Misc <xxx> packs: <xxx> KB

• Packs: refers to mods, resource packs, and mod-provided optional resource packs
• Model file: model json files under "assets/<modid>/models/" folder
• Baked models: models that are baked. There could be more baked models than model files if multiple models are using the same model file but different textures. But since for most models the texture is specified in the model file, the number should not differ a lot (unless the models is added by code).
• Misc packs: packs that are too small to display. This mod summed their size together.