WEBVTT 00:04.440 --> 00:10.940 In this lesson we'll take the concept of improved static resource delivery one step further by configuring 00:10.940 --> 00:16.160 compressed responses or more specifically Jesus ept responses. 00:16.160 --> 00:21.950 What this means is when a client requests a resource typically a static file such as Javascript or C 00:21.950 --> 00:27.620 S S that client can indicate its ability to accept compressed data. 00:27.620 --> 00:34.250 All modern browsers been capable of this meaning we can compress a response on the server typically 00:34.250 --> 00:41.270 using geyser which drastically reduce its size and as a result reduces the time it takes for the client 00:41.270 --> 00:44.990 to receive that response which the client or browser. 00:44.990 --> 00:50.810 In this case then has the responsibility of decompressing before rendering it not something we need 00:50.810 --> 00:54.350 to be concerned with however this happens automatically. 00:54.350 --> 01:02.270 Step 1 then is enabling gs of compression in the hgt context so applying to all of our server and location 01:02.270 --> 01:11.080 blocks said geez up on this being a directive of the HDP Jesus module which comes with thing Genex course 01:11.120 --> 01:13.220 so nothing extra to add. 01:13.220 --> 01:20.060 Also note that this is a standard directive type so enabling that in the HTP context like this means 01:20.150 --> 01:23.480 any child context can very easily override it. 01:23.510 --> 01:25.240 Something to keep in mind. 01:25.550 --> 01:31.780 Next then we need to configure the compression we've just enabled the first direct default set is GC 01:31.840 --> 01:39.710 up comp level which is the amount of compression used a lower number resulting in larger files but requiring 01:39.710 --> 01:47.110 less server resources and a larger number resulting in smaller files but requiring more server resources. 01:47.450 --> 01:54.650 It's important to note however that at levels over 5 the reduction in file size or response size becomes 01:54.650 --> 01:55.740 very minor. 01:55.880 --> 02:01.820 So typically I find three or four to be a good option a decent amount of compression without the need 02:01.820 --> 02:04.630 for much work on the service part. 02:04.640 --> 02:11.990 I'll make this three and then we have to sit the file types or mime types to apply this compression 02:12.020 --> 02:15.470 to G's up types setting. 02:15.500 --> 02:24.600 Any number of mime types as arguments for example text slash C assess and text slash javascript Jesus 02:24.710 --> 02:28.340 types is an array directive so we could also write it like this. 02:28.370 --> 02:35.750 Which I prefer for eligibility that enables and configures gs of compression on responses of this MIME 02:35.750 --> 02:36.430 type. 02:36.620 --> 02:41.960 But remember the client still needs to indicate that they're willing to accept a compressed response 02:42.200 --> 02:43.950 before this will happen. 02:44.000 --> 02:48.710 Which from the previous lesson is with this very header comes in. 02:48.710 --> 02:55.510 This is now saying on this location block the response can vary based on the accept encoding header. 02:55.520 --> 03:03.700 The client sends with the request that variation being compressed or uncompressed reload the configuration 03:04.190 --> 03:08.170 and this time test by requesting style dotsie it says. 03:09.150 --> 03:14.490 Nothing about compression in the headers as we did not indicate that we're willing to accept a compressed 03:14.490 --> 03:22.890 response so to do that then as per this very header this time set our own header on this request using 03:22.920 --> 03:24.910 a capital H flag. 03:25.110 --> 03:27.340 Except in codein. 03:27.450 --> 03:28.230 Up. 03:28.230 --> 03:35.310 This can also indicate more compression formats such as deflate which is C lobe instead of G's up. 03:35.490 --> 03:38.100 But of course that doesn't really apply here. 03:38.250 --> 03:45.330 Enter and this time having indicated that we can accept compressed responses we get content encoding. 03:45.540 --> 03:49.200 Up meaning this response is encoded with Jesus. 03:49.350 --> 03:51.360 Or in other words compressed. 03:51.360 --> 03:52.960 We can actually see this. 03:53.010 --> 03:59.910 If I output the response body instead of the headers only do that uncompressed style that hearsays first 04:00.390 --> 04:01.880 we see that stylesheet. 04:02.890 --> 04:05.770 But request the compressed version however. 04:08.320 --> 04:15.250 And the terminal complains binary output can mess up your terminal as this response is now in binary 04:15.250 --> 04:17.150 format or Jees apt. 04:17.500 --> 04:24.790 So just how much did we save then download these two versions of style dutty assess uncompressed first 04:24.910 --> 04:27.560 as Style dotsie says. 04:28.410 --> 04:37.530 And then compressed as style DOT men dotsie s there nine hundred eighty bytes for the uncompressed style 04:37.530 --> 04:43.920 sheet and four hundred eighty seven bytes for the GS ept styles which we can confirm by listing the 04:43.920 --> 04:48.320 two files Alice style asterisk. 04:48.330 --> 04:54.430 This might not seem lucky yugio amount of data saved but it's more than half the size of this file. 04:54.600 --> 05:00.690 So when dealing with multiple larger files this can really have a massive impact on load times for the 05:00.690 --> 05:01.740 client.