You can create a timer when the client goes into the minimized state, to run the FrameMove() and handle network traffic. This allows the user to continue following, moving, and lets the user receive updates. And then simply kill the timer when going out of the minimized state.
If the client is Maximized and Minimized, it won't run WM_SIZE, so in that case you can kill the timer on WM_QUERYOPEN.
If you you plan on adding the released code to not freeze the window while moving, just holding down the window enters a 500ms delay due too other stuff that needs to be ran. You can ignore this by changing the non-client windows messages, Ie: WM_NCLBUTTONDOWN. You can send a hittest, and use functions like GetCursorPos, SetCapture to the hwnd to get the point of the cursor. By setting a boolean, you can determine that in this state the window would be moving. Then handle the change in position in the client by updating the position with SetWindowPos by using the offset of points from the mouse cursor movement with the mouse move windows messages. Simply on the button up, you would set the bool flag to false. Thus, skipping some extra windows bulk and the client will always render while doing this.
Just a "for your information", if you send a hittest to the window while planning to move the client, in the fashion that I mentioned, you will need to also determine the wparam, that way you don't move the client by pressing the buttons. And you would need to check if a window steals focus to stop the manual movement which I do by just checking WM_ACTIVE with the loword of wparam being WA_INACTIVE.
Just by messing with the windows messages, a lot can be possible.