One place for hosting & domains

      Speed

      Speed Up Your WordPress Website with Gzip Compression


      Keeping your website running at top speed is essential. A speedy website can provide a huge boost to your site’s user experience, search engine visibility, and improve your professionalism and reliability.

       

      Gzip compression is one popular method to speed up your site. While the term may sound technical, the basic concept isn’t too complicated. What’s more, enabling Gzip compression on your WordPress site is surprisingly easy. Let’s find out more!

      An Introduction to Gzip Compression

      compressing the CSS stylesheet with Gzip

      As your site expands, many of its files grow in size as well. This is a natural result of adding more content, plugins, themes, and custom code to your site. All of that new data has to be stored somewhere.

      The downside of larger files is that they often take more time to load when your pages are accessed. This means your visitors will end up waiting longer to view your content — which is never a good thing. To deal with this problem, you need to find a way to make your site’s files smaller without losing any important information.

      This is exactly what Gzip compression does. It reduces the size of your files by ‘compressing’ them, removing unnecessary characters, and reorganizing data more efficiently.

      If you’ve ever ‘zipped’ a folder to make it smaller, this is a similar concept. Gzip compression can reduce the overall size of your pages by up to 70%, and nothing crucial is lost in the process.

      Get Content Delivered Straight to Your Inbox

      Subscribe to our blog and receive great content just like this delivered straight to your inbox.

      How to Enable Gzip Compression on Your WordPress Site (2 Methods)

      There are a lot of ways to speed up your WordPress site. For example, choosing an optimized hosting plan is key. However, Gzip compression can improve your page speeds even further, so it’s worth implementing.

      Below, we’ll show you two ways to get started with Gzip compression. Keep in mind that the first thing you’ll want to do is make sure you have a recent backup of your site in place as a safety precaution. Then you can read through both methods and choose the one you prefer!

      Method 1: Use a Plugin

      You may struggle to find a quality plugin exclusively designed to implement Gzip compression. Fortunately, you don’t need one. Many speed optimization plugins include an option for Gzip compression as a part of their feature sets.

      For a perfect example, check out WP Super Cache:

      WP Super Cache WordPress plugin

      This plugin is primarily a caching solution, which is another smart way to speed up your WordPress site. However, it also enables you to compress your files.

      After installing and activating the plugin, you’ll need to navigate to Settings > WP Super Cache and switch over to the Advanced tab:

      enabling Gzip compression in the WP Super Cache WordPress plugin

      Find the option labeled Compress pages so they’re served more quickly to visitors, and check the box next to it. Then click on the Update Status button to save your changes.

      That’s all you need to do — the plugin will now implement Gzip compression automatically!

      2. Modify Your .htaccess File

      While the above technique is the simplest way of enabling Gzip compression on your WordPress site, some users will be more interested in an alternative method. For instance, if you’re trying to limit the number of plugins you install on your site, you might prefer to implement Gzip compression manually.

      To do this, you’ll need to use the Secure File Transfer Protocol (SFTP). It enables you to directly access (and make changes to) your site’s files.

      If you’ve never used SFTP before, you’ll first want to install a suitable client, such as FileZilla (and brush up on your SFTP skills). Then you’ll need to establish a connection to your site using your hosting credentials.

      Once you have FileZilla set up, it should look something like this:

      editing files in an FTP client

      In the top right quadrant, find the folder named after your website’s domain and select it. Then, in the bottom right quadrant, look for the file called .htaccess. This is one of your site’s core files, so you should always be very careful when making changes to it:

      enabling Gzip compression by editing CSS stylesheet in WordPress

      Right-click on the .htaccess file and select Download to save it to your computer. Then open the file in any text editor (such as Notepad), and paste in the following code:

      <IfModule mod_deflate.c>
      
      # Compress HTML, CSS, JavaScript, Text, XML and fonts
      AddOutputFilterByType DEFLATE application/javascript
      AddOutputFilterByType DEFLATE application/rss+xml
      AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
      AddOutputFilterByType DEFLATE application/x-font
      AddOutputFilterByType DEFLATE application/x-font-opentype
      AddOutputFilterByType DEFLATE application/x-font-otf
      AddOutputFilterByType DEFLATE application/x-font-truetype
      AddOutputFilterByType DEFLATE application/x-font-ttf
      AddOutputFilterByType DEFLATE application/x-javascript
      AddOutputFilterByType DEFLATE application/xhtml+xml
      AddOutputFilterByType DEFLATE application/xml
      AddOutputFilterByType DEFLATE font/opentype
      AddOutputFilterByType DEFLATE font/otf
      AddOutputFilterByType DEFLATE font/ttf
      AddOutputFilterByType DEFLATE image/svg+xml
      AddOutputFilterByType DEFLATE image/x-icon
      AddOutputFilterByType DEFLATE text/css
      AddOutputFilterByType DEFLATE text/html
      AddOutputFilterByType DEFLATE text/javascript
      AddOutputFilterByType DEFLATE text/plain
      AddOutputFilterByType DEFLATE text/xml
      
      # Remove browser bugs (only needed for really old browsers)
      BrowserMatch ^Mozilla/4 gzip-only-text/html
      BrowserMatch ^Mozilla/4\.0[678] no-gzip
      BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
      Header append Vary User-Agent
      
      </IfModule>

      Don’t forget to save your changes to the file. After that, you can re-upload it to your site by copying and pasting it back into your website’s root folder (or simply dragging it there from your computer). Now you’ve enabled Gzip compression on your WordPress website manually!

      Note that this method is for websites with Apache servers. If your site runs on NGINX, we recommend checking out this tutorial on enabling Gzip compression with NGINX.

      Speed Up Your WordPress Site with Gzip Compression

      There are a lot of ways to make sure your WordPress site runs fast and efficiently. For example, you’ll want to choose an optimized hosting plan with a reputation for speed. After that, you can make plenty of smaller tweaks to maximize your site’s performance, such as using Gzip compression to reduce file sizes.

      Do More, Faster, with DreamPress

      DreamPress’ automatic updates, caching, and strong security defenses take WordPress management off your hands so you can focus on your website.

      shared hosting



      Source link

      How To Speed Up Static Web Pages with Varnish Cache Server on Ubuntu 20.04


      The author selected the COVID-19 Relief Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Varnish is a versatile reverse HTTP proxy that caches responses from backend servers in memory so they are served quickly when requested again. It uses HTTP headers to determine whether to cache the responses to a particular request. By default, it does not cache responses with cookies because those are considered client-specific requests; however you can change this setting in the configuration file.

      Besides acting as a caching server, Varnish can be used as a:

      • Web application firewall
      • DDoS attack defender
      • Load balancer
      • Quick fix for unstable backends
      • HTTP router

      There are three locations where the HTTP cache can be saved:

      • Browser: This cache is saved on users’ browsers. It is user-specific and can be used to serve content instead of sending requests to web sites.
      • Proxy: A proxy is an intermediate server that sits between users and servers. It is usually deployed by ISPs and can be used to cache responses that will be requested by multiple users.
      • Reverse Proxy: This kind of proxy is created by the web site’s administrator and can be used to serve content from the network’s edge instead of sending requests to back end servers. This is the kind of cache you will create in this tutorial.

      Note: For more information about HTTP caching, see this tutorial on HTTP headers and caching strategies.

      In this tutorial, you will set up Varnish as a caching reverse proxy server. You’ll then test the setup with Varnish against a non-caching configuration using wrk.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Installing Varnish And Apache

      To start, you’ll install Apache and Varnish. First update apt-get, and then install Apache with these commands:

      • sudo apt-get update
      • sudo apt-get install apache2 -y

      You’ll see output indicating that Apache is being installed.

      After the Apache installation process is complete, install Varnish with this command:

      • sudo apt-get install varnish -y

      You’ll see output indicating that Varnish is being installed.

      Next, make sure both packages installed correctly. First, use this command to check the status of Apache:

      • sudo systemctl status apache2

      The output will look similar to this:

      Output

      root@ubuntu-s-1vcpu-2gb-fra1-01:~# sudo systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2021-08-04 18:58:39 UTC; 4min 10s ago Docs: https://httpd.apache.org/docs/2.4/ Main PID: 2279 (apache2) Tasks: 55 (limit: 2344) Memory: 5.0M CGroup: /system.slice/apache2.service ├─2279 /usr/sbin/apache2 -k start ├─2281 /usr/sbin/apache2 -k start └─2282 /usr/sbin/apache2 -k start Aug 04 18:58:39 ubuntu-s-1vcpu-2gb-fra1-01 systemd[1]: Starting The Apache HTTP Server... Aug 04 18:58:39 ubuntu-s-1vcpu-2gb-fra1-01 apachectl[2278]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' di> Aug 04 18:58:39 ubuntu-s-1vcpu-2gb-fra1-01 systemd[1]: Started The Apache HTTP Server.

      Press the Q key to exit the status command.

      Next, check the status of Varnish with this command:

      • sudo systemctl status varnish

      The output will look similar to this:

      Output

      root@ubuntu-s-1vcpu-2gb-fra1-01:~# sudo systemctl status varnish ● varnish.service - Varnish HTTP accelerator Loaded: loaded (/lib/systemd/system/varnish.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2021-08-04 18:59:09 UTC; 4min 41s ago Docs: https://www.varnish-cache.org/docs/6.1/ man:varnishd Main PID: 3423 (varnishd) Tasks: 217 (limit: 2344) Memory: 10.7M CGroup: /system.slice/varnish.service ├─3423 /usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m └─3447 /usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m Aug 04 18:59:09 ubuntu-s-1vcpu-2gb-fra1-01 systemd[1]: Started Varnish HTTP accelerator. Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Debug: Version: varnish-6.2.1 revision 9f8588e4ab785244e06c3446fe09bf9db5dd8753 Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Version: varnish-6.2.1 revision 9f8588e4ab785244e06c3446fe09bf9db5dd8753 Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Debug: Platform: Linux,5.4.0-73-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Platform: Linux,5.4.0-73-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Debug: Child (3447) Started Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Child (3447) Started Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Info: Child (3447) said Child starts Aug 04 18:59:10 ubuntu-s-1vcpu-2gb-fra1-01 varnishd[3423]: Child (3447) said Child starts

      If you do not see both services up and running, wait a few minutes until they are fully loaded, and keep both of them running.

      Now that you have Apache2 Varnish, installed, you’ll give Varnish something to serve, in this case Apache’s static web page.

      Step 2 — Configuring Varnish To Serve Apache’s Static Web Page

      In the previous step, you installed Varnish, and next you’ll need to configure it. By default, Varnish listens on port 6081 and connects to a local web server on port 8080. You’ll change that to serve the Apache static site from Apache server.

      First, you’ll change Varnish’s listening port to 8080. Usually you would want the listening port to be 80, but because you are running Apache and Varnish on the same server, you’ll use port 8080 for Varnish and port 80 for Apache.

      There is no configuration option to change the listening port for Varnish, so you’ll do it using the command line. You’ll create a file called customexec.conf in a new directory called varnish.service.d in /etc/systemd/system/ that will change the default ports.

      Use the mkdir command to create the new directory:

      • sudo mkdir /etc/systemd/system/varnish.service.d

      Use your favorite text editor to create a new file called customexec.conf :

      • sudo nano /etc/systemd/system/varnish.service.d/customexec.conf

      In customexec.conf, add the following content:

      /etc/systemd/system/varnish.service.d/customexec.conf file

      [Service] ExecStart= ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :8080 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m

      In this file you are changing the Service section of the Varnish configuration. First you remove the old value for the ExecStart option, and then you assign a new value for it.

      The new value specifies the binary file used to run Varnish with the following options:

      • -j: Specifies the jailing mechanism to use. Varnish jails are used to reduce the permissions for the varnish process over various platform-specific methods. Here you’re using the unix mechanism and the user vcache to limit the permissions. This is default for varnish on Ubuntu systems.

      • -F: Indicates that the server should run in the foreground, because systemd expects the main process to keep running so it can track it, and not fork a new process and die.

      • -a: This flag is used to specify the IP address and port for accepting client connections. The IP in this case is empty, which means the server will accept all IPs. The port is set to 8080.

      • -T: This flag specifies the IP address and port for management interface, in this case localhost and port 6082.

      • -f: This flag specifies the default VCL file for Varnish configuration. You will edit this file later in this tutorial to configure Varnish to connect to the Apache server.

      • -S: This flag specifies a shared secret file for authorizing access to the management interface. The /etc/varnish/secret value is the default for Varnish on Ubuntu. You will not use the secret file in this tutorial.

      • -s: This flag indicates where and how to store objects. The value malloc,256m is the default one for Vanish. It means to store various Varnish objects in memory using the malloc system call and a maximum size of 256 megabytes. Other possible values are default, which uses umem when malloc is not available, or file, which stores objects in a file on the disk.

      Save and close the customexec.conf file. Then execute this command to reload the systemd services file from disk:

      • sudo systemctl daemon-reload

      Then restart Varnish for changes to take effect.

      • sudo systemctl restart varnish

      You won’t see any output from these last two commands. To make sure that Varnish is now listening on port 8080, use the netstat command to display all listening TCP sockets on the server.

      • sudo netstat -ltnp | grep 8080

      You’ll see output that looks like this:

      Output

      tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 18689/varnishd tcp6 0 0 :::8080 :::* LISTEN 18689/varnishd

      Now that Varnish is running and listening to port 8080, you need to edit the default configuration file located at /etc/varnish/default.vcl:

      • sudo nano /etc/varnish/default.vcl

      Navigate to the backend default block, and then change .port to 80, as shown here:

      default.vcl file

      # Default backend definition. Set this to point to your content server. backend default { .host = "127.0.0.1"; .port = "80"; }

      Save and close the default.vcl file, then restart Varnish with this command:

      • sudo systemctl restart varnish

      If everything is fine, there won’t be any output. Open http://your_server_ip:8080 in your browser, and you’ll see the Apache static site, opened using Varnish.

      You now have Apache and Varnish running together on the same Droplet, with Apache listening to port 80 and Varnish to port 8080. Next, you’ll compare the response times of both servers using the wrk tool.

      Step 3 — Testing Varnish Using wrk

      wrk is a modern HTTP benchmarking tool. It is written in C, and can be used to load test web servers with many requests per second. In this step, you’ll use wrk to run tests against Apache and Varnish and then compare the results.

      First you’ll need to install wrk by building it from source. Start by installing some build tools for C and git, which are required for building wrk from source:

      • sudo apt-get install build-essential libssl-dev git unzip -y

      Then clone the git repository for wrk into the wrk directory:

      • git clone https://github.com/wg/wrk.git wrk

      Change to that new directory:

      Build the wrk executable with the make command:

      Copy wrk to the /usr/local/bin directory so you can access it from anywhere in your directory structure:

      • sudo cp wrk /usr/local/bin

      Now that you have wrk installed, use it to test the responsiveness of Apache with this command:

      • wrk -t2 -c1000 -d30s --latency http://server_ip/

      This command uses the following arguments:

      • -t2: This means run two threads.
      • -c1000: Keep 1000 HTTP connections open.
      • -d30s: Run the test for 30 seconds.
      • --latency: Print latency statistics.

      Wait 30 seconds until the test is done, and you’ll see output similar to this:

      output

      Running 30s test @ http://68.183.115.151/ 2 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 44.45ms 104.50ms 1.74s 91.20% Req/Sec 8.29k 1.07k 12.40k 71.00% Latency Distribution 50% 11.59ms 75% 22.73ms 90% 116.16ms 99% 494.90ms 494677 requests in 30.04s, 5.15GB read Socket errors: connect 0, read 8369, write 0, timeout 69 Requests/sec: 16465.85 Transfer/sec: 175.45MB

      In this test, the average latency is 44.45ms, there were 494,677 total requests, 8,369 read errors, and 69 timeout errors. The exact numbers will vary in your installation.

      Now run the same test again for the Varnish server using this command:

      • wrk -t2 -c1000 -d30s --latency http://server_ip:8080/

      Wait 30 seconds until the test is done, and you’ll see output similar to this:

      output

      Running 30s test @ http://68.183.115.151:8080/ 2 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 14.41ms 13.70ms 602.49ms 90.05% Req/Sec 6.67k 401.10 8.74k 83.33% Latency Distribution 50% 13.03ms 75% 17.69ms 90% 24.72ms 99% 58.22ms 398346 requests in 30.06s, 4.18GB read Socket errors: connect 0, read 19, write 0, timeout 0 Requests/sec: 13253.60 Transfer/sec: 142.48MB

      The output you see will likely be somewhat different, but the latency will be lower for Varnish than for Apache. In this case, the average latency is 14.41ms, there were 398,346 total requests, and no errors.

      In these tests, with Apache the average response time was 44.45ms with 8,438 errors, while Varnish achieved an increase in speed to 14.41ms, and also had no errors. This is because Varnish cached the response in memory and served it for later requests, unlike Apache, which needs to read from disk almost every time the resource is requested.

      Conclusion

      In this tutorial, you configured Varnish as a reverse proxy caching server for a static web site. You saw how to use basic HTTP caching to improve performance, and you used wrk to run load tests for the Apache and Varnish servers to compare the results.

      You’ve seen that the Varnish cache server speeds up your static site by serving content from main memory and not requesting it from the back end Apache server every time a new request arrives. For more information about other uses of Varnish, see the official documentation.



      Source link

      How to Use a Remote Docker Server to Speed Up Your Workflow


      Introduction

      Building CPU-intensive images and binaries is a very slow and time-consuming process that can turn your laptop into a space heater at times. Pushing Docker images on a slow connection takes a long time, too. Luckily, there’s an easy fix for these issues. Docker lets you offload all those tasks to a remote server so your local machine doesn’t have to do that hard work.

      This feature was introduced in Docker 18.09. It brings support for connecting to a Docker host remotely via SSH. It requires very little configuration on the client, and only needs a regular Docker server without any special config running on a remote machine. Prior to Docker 18.09, you had to use Docker Machine to create a remote Docker server and then configure the local Docker environment to use it. This new method removes that additional complexity.

      In this tutorial, you’ll create a Droplet to host the remote Docker server and configure the docker command on your local machine to use it.

      Prerequisites

      To follow this tutorial, you’ll need:

      • A DigitalOcean account. You can create an account if you don’t have one already.
      • Docker installed on your local machine or development server. If you are working with Ubuntu 18.04, follow Steps 1 and 2 of How To Install and Use Docker on Ubuntu 18.04; otherwise, follow the official documentation for information about installing on other operating systems. Be sure to add your non-root user to the docker group, as described in Step 2 of the linked tutorial.

      Step 1 – Creating the Docker Host

      To get started, spin up a Droplet with a decent amount of processing power. The CPU Optimized plans are perfect for this purpose, but Standard ones work just as well. If you will be compiling resource-intensive programs, the CPU Optimized plans provide dedicated CPU cores which allow for faster builds. Otherwise, the Standard plans offer a more balanced CPU to RAM ratio.

      The Docker One-click image takes care of all of the setup for us. Follow this link to create a 16GB/8vCPU CPU-Optimized Droplet with Docker from the control panel.

      Alternatively, you can use doctl to create the Droplet from your local command line. To install it, follow the instructions in the doctl README file on GitHub.

      The following command creates a new 16GB/8vCPU CPU-Optimized Droplet in the FRA1 region based on the Docker One-click image:

      • doctl compute droplet create docker-host
      • --image docker-18-04
      • --region fra1
      • --size c-8
      • --wait
      • --ssh-keys $(doctl compute ssh-key list --format ID --no-header | sed 's/$/,/' | tr -d 'n' | sed 's/,$//')

      The doctl command uses the ssh-keys value to specify which SSH keys it should apply to your new Droplet. We use a subshell to call doctl compute ssh-key-list to retrieve the SSH keys associated with your DigitalOcean account, and then parse the results using the sed and tr commands to format the data in the correct format. This command includes all of your account’s SSH keys, but you can replace the highlighted subcommand with the fingerprint of any key you have in your account.

      Once the Droplet is created you’ll see its IP address among other details:

      Output

      ID Name Public IPv4 Private IPv4 Public IPv6 Memory VCPUs Disk Region Image Status Tags Features Volumes 148681562 docker-host your_server_ip 16384 8 100 fra1 Ubuntu Docker 5:18.09.6~3 on 18.04 active

      You can learn more about using the doctl command in the tutorial How To Use doctl, the Official DigitalOcean Command-Line Client.

      When the Droplet is created, you’ll have a ready to use Docker server. For security purposes, create a Linux user to use instead of root.

      First, connect to the Droplet with SSH as the root user:

      Once connected, add a new user. This command adds one named sammy:

      Then add the user to the docker group to give it permission to run commands on the Docker host.

      • sudo usermod -aG docker sammy

      Finally, exit from the remote server by typing exit.

      Now that the server is ready, let's configure the local docker command to use it.

      Step 2 – Configuring Docker to Use the Remote Host

      To use the remote host as your Docker host instead of your local machine, set the DOCKER_HOST environment variable to point to the remote host. This variable will instruct the Docker CLI client to connect to the remote server.

      • export DOCKER_HOST=ssh://sammy@your_server_ip

      Now any Docker command you run will be run on the Droplet. For example, if you start a web server container and expose a port, it will be run on the Droplet and will be accessible through the port you exposed on the Droplet's IP address.

      To verify that you're accessing the Droplet as the Docker host, run docker info.

      You will see your Droplet's hostname listed in the Name field like so:

      Output

      … Name: docker-host

      One thing to keep in mind is that when you run a docker build command, the build context (all files and folders accessible from the Dockerfile) will be sent to the host and then the build process will run. Depending on the size of the build context and the amount of files, it may take a longer time compared to building the image on a local machine. One solution would be to create a new directory dedicated to the Docker image and copy or link only the files that will be used in the image so that no unneeded files will be uploaded inadvertently.

      Conclusion

      You've created a remote Docker host and connected to it locally. The next time your laptop's battery is running low or you need to build a heavy Docker image, use your shiny remote Docker server instead of your local machine.

      You might also be interested in learning how to optimize Docker images for production, or how to optimize them specifically for Kubernetes.



      Source link