Big Size Database and increasing number of users Me and my colleagues are using quite big size normalized database. 

Basically it's used for warehouse management and daily minimum 100 of the user perform data manipulation operations. 

80% of the users access stock information from web. 
20% users are from the warehouse operation team. 

Most of the time in a day, warehouse operation team performs major operations of stock taking, stock adjustment, sales, purchases, reporting etc.. But at the same time web users get quite slow response from SQL Database. 

Keeping in view increasing number of web users, my question is how I could make the web access faster at the same time when major operations/transactions are running in the background?

As web users are accessing subset of the tables which are being used by Operations team, what strategy I could implement to keep the database responsive as well sync at same time?

Please bear with my language skills, I hope this is right place to ask this question, otherwise please guide.
You're asking a scaling issue which can be solved in many different ways using different technologies based on your current restraints and environments.  If the issue is coming from locking you can change the isolation level to snapshot isolation if you don't mind seeing the old value until the new ones is complete.  This is good if you have plenty of TempDB space and can afford an extra 14 or so bytes per row for the version overhead.

You can use snapshots to query the old data but as new data is added expect slower performance if your snapshot disks aren't fast enough to query the stale data.  

You can mirror the data to a different server, read that from a snapshot and update the snapshot after all write operations are complete and replicated.  This will cause your queries to fail while you make a new snapshot but that's very fast, or you could just snapshot by day and delete the old one.  The problem with this is that standard edition of SQL Server requires you write to the mirrored pair first, then to the primary.  This means if the secondary is down the writes on the primary won't commit.  This isn't bad in your scenario actually since they only get updated once per day and if the network is fast enough, along with fast enough disks on the 2nd side to snapshot report from and write to, you're good to go.

Do you have 2 servers?  If so, I'd say mirror to the secondary in this scenario and always perform your reads against a snapshot which get's recreated once a day after the primary is updated and mirrored over.

Edit:
Note there is a HUGE difference between "Database Snapshots" and "Snapshot Isolation".  Snapshot Isolation works on a ROW level and is done to let you read the old value while the new one is being updated.  "Database Snapshots" work by making a copy of the old data page when it changes and referencing that, and it will stay until you drop it.  Note neither of these will help you if the issue is memory or disk IO.