yup mas bro , emmhh penjelasan schema di atas itu adalah browser decompress display page adalah browser menampilkan jumlah size yg telah di compress oleh server yaitu dr 100 kb zip file menjadi 10 kb
ini schema sebelum di compress
1. Browser: Hey,
GET me /index.html
2. Server: Ok, let me see if index.html is lying around...
3. Server: Found it! Here's your response code (200 OK) and I'm sending the file.
4. Browser: 100KB? Ouch... waiting, waiting... ok, it's loaded.
dan ini jika sudah di gzipping / optimize :
1. Browser: Hey, can I
GET index.html? I'll take a compressed version if you've got it.
2. Server: Let me find the file... yep, it's here. And you'll take a compressed version? Awesome.
3. Server: Ok, I've found index.html (200 OK), am zipping it and sending it over.
4. Browser: Great! It's only 10KB. I'll unzip it and show the user.
dan mengenai ini :
CPU-load: Compressing content on-the-fly uses CPU time and saves bandwidth. Usually this is a great tradeoff given the speed of compression. There are ways to pre-compress static content and send over the compressed versions. This requires more configuration; even if it's not possible, compressing output may still be a net win. Using CPU cycles for a faster user experience is well worth it, given the short attention spans on the web.
ini adalah cpu server yg mempunyai tugas mengezipping contentnya, dalam artian adalah server , memang akan makan cpu untuk processnya seperti di post sebelumnya, jd bukan dr browser cpu client yg akses mas.