What's the device and what's the link you're most concerned about?
As Georg notes, there are many ways to provide QoS, what's best depends on what you have to work with and what QoS needs you're trying to meet.
If you're a QoS "beginner" I would recommend you start with a simple FQ policy in class-default. This often addresses 90%, or better, of real world QoS needs vs. using typical interface default FIFO.
You don't need much for this configuration, for example:
policy-map sample
class class-default
fair-queue
interface x
service-policy output sample
Next most important thing would be, if your physical WAN hand-off has more bandwidth than your WAN supports end-to-end, is to "shape" for the end-to-end bandwidth.
For example if your WAN has a FE physical hand-off, but you're contracted rate is 50 Mbps, then something like:
policy-map sampleparent
class class-default
shape average 42500000
service-policy samplechild
policy-map samplechild
class class-default
fair-queue
interface x
service-policy output sampleparent
In the above I've allowed 15% of the CIR for L2 overhead as I believe most Cisco shapers only count L3 bandwidth.
If you have real-time traffic, like VoIP, you'll often need a LLQ class for that.
Georg shows using LLQ for your "important" traffic, but I would recommend against that for a couple of reasons. First, you may eventually really need LLQ for something like VoIP but you now need to deal with the traffic that you've already placed in LLQ that can no longer stay there if you want VoIP to perform correctly. Second, LLQ has an implicit policer, which you're more likely to bump into with elastic bandwidth traffic.
Better, I would suggest, would be a multi-tiered set of classes. Much can be accomplished with the following:
policy-map sample4class
class real-time
priority percent 33
class foreground
bandwidth remaining percent 81
fair-queue
class background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
To use the above, real-time should only have traffic that needs ultimate priority over everything else, such as VoIP bearer traffic.
Most other traffic should go into class-default, where FQ will share bandwidth between flows.
Traffic that really, really needs better service than class-default's FQ should be directed to the foreground class. Use much care for what you direct to this class.
Lastly, if you have traffic that isn't in a rush to complete (i.e. not time critical), direct it to the background class. Understand, traffic in this class can still use all the link's bandwidth, but it will effectively step aside to allow other traffic to use the bandwidth first.
PS:
Oh, Georg also shows using ACLs to match traffic. That's fine, but later routers often support traffic matching using NBAR. If you have access to NBAR it often is "smarter" than ACL matching. For example, if you're trying to match HTTP traffic, rather than looking for port 80, I recall it actually looks for HTTP text within the packet regardless of the port number. I also recall, it can even match URLs within the HTTP text.
