Like most things in game development, and especially in game graphics, the answer is "it depends"
The resolution of your texture can have an impact on rendering speed. The more pixels it contains, the more raw data there is to upload to the GPU, and the less of the texture we can fit in cache at a time, so the shader might hit more pauses while it waits for the right part of the texture to get pulled into cache.
Using mipmapping can reduce the impact of this. With mipmaps, we store a chain of downsized versions of the texture, which at first sounds like even more memory to schlep around. But it lets us read from the smaller versions when the texture is displayed at a small size on the screen (like a distant object in perspective), so our samples make better use of the texture cache, rather than jumping all over. This also reduces aliasing.
The content of your textures doesn't have an impact on rendering efficiency most of the time.
A colour is just a bunch of numbers as far as the GPU is concerned, so it doesn't care much what those numbers are, it just funnels them through its math the same way. It doesn't do anything fancy like remembering "Oh, I've seen a pixel in this green before, I'll just re-use the same output I calculated last time I saw this input" so whether your texture is all one colour or random sparkles, your GPU is doing the same work.
Unlike formats like PNG & JPG, which compress more efficiently in predictable areas of the image, and eat up more bits in complex regions, GPU texture formats like BTC, ETC, PVRTC, or even raw RGBA use a fixed number of bits per block of pixels. So making your texture more or less detailed while keeping the same compression format won't change its data size or impact data transfer and cache-related efficiency.
But, if you use a particular kind of detail that your previous compression doesn't preserve well, you might be forced to change your whole image to use a different format, which could again change its data size.
Shader Branching & Indirection
Here's the biggest asterisk in the situation: you might be using this texture colour input to make decisions, like an
if() branch. Here, detail matters for speed.
GPU shading units work on blocks of pixels in batches, running the same instructions in parallel on multiple streams of data. So when some pixels in the block take one branch of the
if and other pixels take the other, the whole batch has to go through both branches (masking out the results that don't apply to one set of pixels or the other)
If your input changes in a smooth/predictable way, then you'll likely have many blocks that only need to take a single branch, and these both-branch cases will be limited to narrow bands around the transition border. But if your input is random-ish, we'd expect most blocks to take both branches and slow down the rendering.
This can also happen if you're using one texture to control lookups into a second texture, like a distortion or index map. If the first texture jumps around randomly, then we'll be sampling from scattered, random-ish spots of the second texture, making less consistent use of our texture cache and waiting longer to get the data we need, on average.
So, overall: no, the content of the texture doesn't have much impact on rendering speed, except for the cases when it does. ;)