How can I fix delay between Instruction and Program Counter?
What you've encountered there are the problems that come with instruction pipelining. I assume that you're going to synthesize your processor for running it on an FPGA at some point, so removing the register between the instruction memory and the rest of the CPU is sadly not an option.
To fix this, you have three options.

Ignore the problem. After all, your processor still behaves in a deterministic way - the only problem is that it will execute an additional instruction after a branch. This is called a branch delay slot, which means that the instruction that comes after a branch will be executed as if it was actually before the branch. A lot of processors have this kind of delay slot and compilers can handle them just fine. Early MIPS processors had delay slots, too.
Unconditionally stall the pipeline after a branch got fetched. This means that you halt the program counter for one cycle and insert a NOP into the pipeline whenever you encounter a branch, which effectively hides the delay slot.
Flush the pipeline when a branch is taken. This means that your processor keeps executing the instruction stream normally until it detects that it has to jump. At this point, it throws away all the instructions after the jump that it has already fetched. In your case, there would only be a single instruction to throw away.

You might also take a look at how classic RISC pipelines are organized and what a hazard is in a pipeline. Once you implement memory accesses in your processor, you might also come across hazards caused by data loaded from memory not being available fast enough. You can resolve these issues in a similar way by either stalling the pipeline or accepting that you have so-called load delay slots, which means that the data loaded from memory isn't available immediately to the instruction following the load. Some processors have this kind of delay slot, too, although it's less common than branch delay slots.