To start with the English definitions again:
When we say that two or more things are synchronous we may just mean that they are happening at the same time, or we may more specifically mean that they are keeping pace with each other.
Asynchronous refers to the lack of whatever quality we're using synchronous to talk about.
One case is in communications. With a synchronous communication, we need two devices to keep in step with each other. This may refer to the timing of bits sent along a wire or other medium, all the way up to the higher communication protocols built on top of that.
With an asynchronous communication, we do not need two devices to keep in step, and one can race ahead or fall behind without breaking the communication. Again, this may refer to the low-level transmission of bits, all the way up to higher communication protocols (some like TCP/IP may even allow bits of the message to arrive out of order and be put back into order again later).
While there's generally more work involved in making any given layer work asynchronously, there's generally advantages as it's more reliable (won't break due to timing issues), more flexible (being able to build a system on top of media that operate at variable speeds rather than lock into the lowest speed you can guarantee), and hence it can also even make things easier at the layer above.
As we can see, this relates directly to the normal English-language sense of synchronous where two or more things are keeping pace with each other.
Now, another case is with multithreaded programming (much of what I'll say now also goes for multiprocess systems with communication between them, and some other cases, but I'll just stay with multithreading for the description). When we have a multithreaded program, different parts of it can run simultaneously (or concurrently). Sometimes, it may be necessary to coordinate the work of these threads, for example to collate final results, or to make use of a shared resource that can only tolerate access from one thread at a time.
When we need to synchronise different threads like this, we are using synchronisation. However, the less we can have different threads depend on each other like this, the more efficient things would be overall, because one suffering a delay will not hurt the others.
For that reason, we have a variety of techniques for dealing with I/O, accessing APIs, or delegating work to other machines which are designed to not require this sort of synchronisation between different threads, but will handle the fact that we then can't depend upon the success or failure happening to any given time-frame. Since these simultaneous processes need not be synchronised in the sense of being kept in time with each other, we call each of these techniques asynchronous.
Again, we can look back at the general English definitions and see why they are called what they are called, at least in comparison to each other.
So we have another option: We start a network operation, and then leave it to run and our script continues until it is finished. When the network operation concludes, this triggers an event that lets our single thread act on the results.
So there we have an answer that is perhaps too programming-related to suit EL&U and too English-language focused to suit migrating back to Stackoverflow, but an answer all the same.
*Though different scripts can run on different threads in e.g. different server requests for server-side script, or different tabs on a browser for client-side web scripts.