Updating log table in an effective manner
Do you need the count as you go along? If not,  drop the count column. Insert a row for each event as it happens. Aggregate the rows afterwards in some async batch process. Maybe have a monotonic system-generated number if you only want to touch each event once. If you use a datetime instead of an integer you can get aggregates across pages over time as well as over pages.
Up front I'm going to say I'm no expert on MySQL's internals. Take the following as unproven until you've researched the documentation and tested it in your own environment for yourself.
The type of workload you describe can be slow because each write requires the previous thread's write to complete so it knows what new value to write. If the previous thread wrote value 6 my thread has to read that 6 in order to increment it to 7, and the thread after me has to wait on my write so it can read 7 and increment it to 8. In the worst case, with a single page being served by all clients, the system becomes, essentially, single-threaded at this count.
By performing inserts instead of updates the inter-thread dependency is removed. Each thread can write its event when it's ready to. Throughput is limited only by the ability of the storage to persist bytes.
This approach treats the receiving table as a log. You want to choose an implementation which facilitates this. Likely there will be no indexes on this table as they increase the number of IOs required per event and are a further source of possible contention. Different storage engines have different support and performance characteristics for un-sequenced, store-it-anywhere-you-can writes.