I have multiple components that are lagging
As already stated in Look Alterno's comment and dannyf's answer, the
Arduinos are single-core, and they cannot perform several processes in
parallel. However, unless you have sub-millisecond timing requirements,
this should not be an issue. Your Arduino can just perform one task at a
time and, if it goes fast enough, it should meet your requirements.

So the good question to ask is: given the tasks you want it to
perform, can the Arduino do them while keeping the latency below some
threshold of your choosing? Latency is the time lag between the Arduino
receiving some stimulus (say, a change in light level) and it performing
the required action (e.g. moving a servo). For the kind of actuations
you mention in the question (servos, LEDs, buzzer), it makes little
sense to require sub-millisecond latency, and the Arduino (any Arduino)
should be able to meet your timing requirements hands down.

If your Arduino is really slow, this is generally because you have
something in your program that blocks the CPU for too long. It may be
some process that is very CPU-intensive, but this is unlikely because
you can do a significant amount of computation in one millisecond. More
likely, you are calling some blocking library function: a function
that blocks the CPU inside a do-nothing loop while it waits for some
external event to happen. You will have to go through your code and
hunt down any such blocking calls.


  I have multiple components such as LED's


LEDs are no issue. You can switch them on or off with a digital pin.
Once switched on, you don't need to do anything to keep them on. They
only consume a tiny bit of CPU time when you switch their state, but
none when you leave them in a fixed state.

If you want to dim an LED, then you will have to toggle it on and off
very fast. You can do this using analogWrite() on a PWM-capable pin.
Then, the toggling is done by a hardware timer, and it does not cost you
any CPU time. If you are short of PWM pins, you can also do the toggling
by software, but this will obviously cost you some CPU time.


  servos


Servos are typically driven using the Servo library. This uses a
combination of hardware (a timer for generating interrupts) and software
(an interrupt service routine that sends the control signals to the
servos). The CPU load should be small, unless you have a lot of servos.
Expect the interrupt to add some latency to the rest of your program.
Something like a few tens of microseconds or so (I haven't measured it).

Also, the servo library will use one of your timers, so you loose the
PWM feature on a couple of pins.


  photoresistor


You typically read a photoresistor with analogRead(). This
is a blocking function: it blocks the CPU while it waits for the ADC to
do its conversion. It will eat about 110&nbsp;µs every time you call it,
so it is probably not such a big deal.


  buzzer


You switch a self-drive buzzer on and off just like an LED, with any
digital pin. If it's an external drive buzzer, you will have to
continuously toggle it. This is typically done with the tone()
function, which uses Timer 2 and costs you no CPU time.


  ultrasound


Ultrasound sonars are typically read using pulseIn(). This is a
blocking function, and often a very serious offender: it block the CPU
while waiting for the echo to come back. If the target is 16&nbsp;cm
from the sonar, you will have to wait for about 1&nbsp;ms, and
proportionately longer for a target further away. If the sonar cannot
see a target, pulseIn() will wait until it times out, and the default
timeout is a whopping full second!

If you are using pulseIn(), the first thing to do is to make sure you
provide an explicit timeout in the call. Make that timeout slightly
longer than the echo time for the longest distance you want to sense. If
that is still too long, you will have to look for a non-blocking
alternative to pulseIn(). You may find some on the Web.


  delay()


You did not mention delay() in you question. You are not using
delay(), right? If you are, then you only get what you are asking for.