Acceleration of the web enabled applications is not simply compression. In fact, there are many factors that slow the delivery of data. Compression alone does not always solve the problem. This is the case with server processing times and network latency, that is, the prolonged time a packet takes to travel from one point to another owning to distance between server and the browser (or any other HTTP agent).
Furthermore, there are many types of data, such as images and videos that are already compressed and therefore cannot be reduced further.
In fact, on average, uncompressible graphical components make up the largest part of data transfers both in volume and in number of requests (98% of HTTP requests and 70% of volume).
Reduction of the data payload is one factor in improving response time.
Addressing propagation times
Propagation time is the time a packet takes to cross the network from one point to another. It is therefore comparable to a shockwave in a medium or an electrical wave in a cable. This time can be measured using the ping command. To be more precise, ping measures the time a packet takes to reach its destination and return, also known as Round Trip Time (RTT). In a local area network (LAN), this time is negligible - usually only a few milliseconds.
On the Internet, this time can reach hundreds milliseconds because of the physical distances involved and the large number of routers and other pieces of equipment.
The result of a ping can therefore be used to measure the distance between two points on the network. Thus, it is possible to say that we are at 70 ms away from www.someothersite.int.
For example, France is 50 ms away from the rest of Western Europe, 120 ms away from the East Coast of North America and about 220 ms from the West Coast. If the connection is routed through a satellite, propagation times exceed 600 ms. A round trip via satellite requires the data to travel four times the distance between Earth and geostationary orbit, that is, four times 37,000km or about 150,000 km, which takes 500 ms.
How to address propagation times
It is easy to see that compression has a diminishing effect when the propagation time is large. A key aspect of the solution in this case is to avoid transferring all the data all the way. BoostEdge makes this possible.
Remote Cache Control
Remote cache control involves the optimized use of caches in the proxy chain and, in particular, the browser's own cache. BoostEdge's HTTP service can fine-tune the caching directives, thereby controlling caching management throughout the proxy chain.
The DynaFlex system allows for very precise configuration of data caching, even URL by URL. This means, for instance, that a logo can be given a lifetime of three months, while icons will be cached indefinitely and some other images for only for a few minutes.
Thanks to this system, customers see a dramatic decrease in the number of requests submitted to the actual HTTP server. The rate of decrease is roughly proportional to the number of components in the HTML page. For example, a page containing 50 components will typically see requests divided by 50. Under these conditions, it is easy to see just how efficient remote cache control really is.
An alternate solution is to move the data closer to the browser. In this case, a network of regional caches is required, and the browser must be configured to submit its graphical requests to the closest cache. This type of network is called a CDN (Content Delivery Network). BoostEdge can be used to easily incorporate a website into a CDN without needing any domain-name delegation.