I agree with most of what @user140417 said (though I agree with Deduplicator on the call to pow). So sticking strictly to performance, I have the following recommendations.

Precompute Everything You Can

You are calculating the real and imaginary parts on every iteration of your inner loop in main(). This is costly. Every row will have the same real values and every column will have the same imaginary values. So pre-calculate 1 row of reals and 1 row of imaginaries before starting the main loop.

It's the same situation with your coloring. Since you know maxN, you can have 3 arrays - one for the red channel, one for the green channel, and one for the blue channel. Just pre-calculate all maxN possible values. Then in the inner loop, it's just a table look-up rather than a calculation.

Use SIMD Techniques

Much of your math is computing the same loop for different sets of floating point numbers. This is exactly the kind of thing that SIMD instruction sets like SSE, AVX, etc. were invented for. You can compute 2 or 4 values per instruction, allowing you to significantly improve the speed of your implementation. You can take it even further with…

Multiple Threads

If you break the input area up into either tiles or strips, you can have multiple threads, each working on a different tile or strip at the same time. On multi-core machines this will speed things up in a nearly linear fashion (in my experience) - up to a point. Combine that with SIMD instructions and you can really get things moving!

Use the GPU

If you really want to make things fast, you can write a GPU implementation using OpenGL compute shaders, or OpenCL kernels, or whatever other library you like to use. GPUs generally have hundreds to thousands of cores of floating point processors making this a really good fit.

Readability

Don't include bits/stdc++.h

This is a non-portable header file that pulls in way more than needed, increasing compilation time and binary size.

Don't use using namespace std;

This combined with the above greatly pollutes the global namespace. If you ever decide to use a third party library (for precision math, image drawing, or what have you) there is a high probability you'll run into conflicts.

Use more descriptive variable names

All of the zr, zi, et al. is not only hard to read but easy to make a fatal typo that's hard to debug. You may as well use std::complex or at the least a std::pair. If you later decide to add the ability to zoom or pan your code readability will rapidly diminish if you continue to use those types of variable names.

Rename mapToReal and mapToImaginary

Maybe you are using the mathematically correct definition, but from what I can tell a better name for the function would be "normalize" or "scale", as "map" is too abstract/vague.

Optimization

Factor out the arithmetic inside findMandelbrot

You are doing a total of (I count) 6 multiplications which can be reduced to three if you refactor the code slightly:

std::complex z{0, 0};
std::complex square_temp{0, 0};
while (square_tmp.real + square_tmp.imag <= 4.0) {
    z.imag = std::pow(z.real + z.imag, 2.0) - square_temp.real - square_temp.imag;
    z.imag += c.imag;
    z.real = square_temp.real - square_temp.imag + c.real;
    square_temp.real = std::pow(z.real, 2);
    square_temp.imag = std::pow(z.imag, 2);
}
// Note code untested

Consider using threads/workers

It's possible to gain a speed increase if you pass chunks of the image to render to multiple threads. How you decide to implement this up to you.