If drawing a single VertexArray using a single Texture is already too slow for your purposes, the only way you can get better performance is to resort to raw OpenGL. This is pretty much where you will hit the SFML performance limit.
There are always 2 main things to consider. We assume you are currently GPU-bound (otherwise this discussion wouldn't make much sense). Depending on your graphics hardware, they might have general purpose compute units, or if you intend to support much older hardware, they have a fixed number of compute units per pipeline stage. Having general purpose compute units means it is easier for the GPU to maintain 100% utilization because it will shift the units to different stages according to what is needed more. This also means it is easier to optimize hotspots because you can easily determine where most of the GPU time is spent. Having a fixed number of shaders per stage as was the case with older hardware, you might have a bottleneck that is preventing another bottleneck from appearing during your measurements, thus it becomes a multi-stage optimization process to get all pipeline stages to 100% utilization if that is even possible (it occurred so rarely that it was the motivation to go general purpose).
What I can say from experience in writing high performance OpenGL code is that, most of the time spent in the GPU is during geometry processing and buffer operations. The former is governed by the amount of compute resources the GPU has available and the latter by the memory architecture/throughput (often referred to by fillrate). The goal is to minimize whatever is dominating the total draw time. To determine this, you need special tools provided by AMD/Nvidia that can read internal counters.
To reduce geometry processing load, you can try to cull what can't be seen anyway in a culling pass on the CPU before sending it to the GPU. This will raise CPU load a bit but will reduce CPU to GPU transfers (if it matters) and increase framerate if that is what the GPU is doing most of the time. There are many well-known occlusion and frustum culling algorithms, I'll leave it up to you to look for them.
To minimize buffer operations, you need to reduce the amount of data written to each of the framebuffers (colour, depth, stencil, etc.) every frame. The first easy way to do this is to mask off buffers you don't intend to use anyway so they aren't written to during drawing. Since SFML doesn't use more buffers than it needs to, this is already the case. Another well known way to do this is to reduce overdraw, i.e. drawing to the same framebuffer pixel over and over again. If you draw back to front, as SFML does, there is no way the GPU can optimize this. SFML does this because this is required for trivial blending support, and because SFML doesn't want to force the user to use a depth buffer. What you will see in a typical "SFML-only" application is a very high level of overdraw, but that doesn't impact performance in a significant way for most applications. If you draw front to back, with depth buffer support, the GPU can perform what is known as "early Z-cull" and discard a fragment relatively early in the pipeline once it has determined that it will be behind something else anyway thus skipping everything thereafter including the expensive buffer operations.
There are so many more ways to optimize drawing utilizing state of the art features of the GPU, but as I said, if drawing with a VertexArray is not good enough for you, you have reached SFML's limits.
