Moving from HTTP to HTTPS 3: Troubleshooting and DIY solutions

Moving from HTTP to HTTPS 3: Troubleshooting and DIY solutions - Plesk

One thing is quite clear- HTTPS is here for good. When SSL certificates give you HTTPS status, you’re saving user data from hackers, making the internet a safer place. You’re also increasing online transactions on e-commerce sites. That’s why most serious website owners have already migrated from HTTP to HTTPS – or are attempting it.

However, even with a host of benefits for a Google-friendly HTTPS site, there are certain technical issues associated with its integration or maintenance that may puzzle even technical users. Let’s now talk about such issues and the best possible ways to resolve them.

Optimizing Speed and Performance

This article presented some tricky errors along with their easy, DIY solutions. Let us know in the comments if we’ve managed to keep the instructions clear and simple and if you performed all the steps accurately.

Optimizing Speed and Performance - Ruby on Rails vs PHP

It’s not uncommon to experience site performance/speed issues after upgrading to HTTPS. SSL-enabled sites go through a series of additional verification processes when a visitor enters. One of the key processes is the handshake that requires a significant amount of CPU power. Here are a few actionable tips that can minimize the operation series and resolve this issue.

  1. Save time by sending multiple requests through a single connection. For that purpose, you need to enable Keep-Alive connections.
  2. Shave time by reusing the SSL session parameters. It will eliminate the SSL handshakes requirements for subsequent or parallel connections.
  3. SSL session cache stores multiple sessions. This cache is shared between all the workers. Use ssl_session_cache directive to enable it.
  4. There are 4000 sessions per megabyte of cache and its default timeout is 5 minutes However, you can increase this time for the better results by using the directive ssl_session_timeout.
  5. To further enhance your website speed by 50-300%, you may also consider the downloadable Speed Kit extension on Plesk.

Issues regarding SSL certificates

Issues regarding SSL certificates - Plesk

SSL Certificate Chains

Another tricky situation is when browsers refuse to accept a certificate, even from a reputed authorized CA. The most popular browsers generally have an inbuilt certificate base containing variously authorized and reputed CAs. However, the reputed CAs use intermediate certificates to sign the server certificate.

The series of chained certificates are provided by the CAs that ultimately link to the root certificate. These intermediate certificates aren’t in the browsers’ inbuilt certificate store and it causes the error. Here are the actionable tips you can follow.

  1. Ideally, the chained certificates should follow the server certificates in order to enable the operations/process.
  2. If you’re non-technical, it’s good to get help from a professional or CA.
  3. Open certificate details and :certification path will reveal the problem areas.
  4. Communicate with your CA if you find difficulty installing an intermediate certificate.

Invalid SSL Certificate

If you try installing the certificate with incorrect details, you’ll get this error. Here’s what to do.

  1. Let’s Encrypt users can use the renewal command to renew an SSL certificate.
  2. If you purchased from another CA, ask them for an SSL certificate renewal.
  3. Make sure the CA is reputable and recognized by popular browsers.

Outdated SSL certificate

As the name suggests you need to renew your SSL certificate because it is now past its due date or has some validity issues. If your browser doesn’t support SNI, then updating its version can resolve the issue. You may also try revisiting the same page.

The Mixed Content Issue

When you use an HTTPS domain as a path to send HTTP elements, it causes the mixed content error. Basically, you’re trying to mix the different elements (HTTP and HTTPS) on the same platform. Here’s how to solve it.

  1. Just visit the console tab in chrome dev tools where you can find a series of elements. If the elements are hard-coded, you need to modify the URL manually. For external resources just replace the HTTP versions with HTTPS. If the external resources haven’t yet transferred to HTTPS, you can send them a request. Alternatively, you can also look for the HTTPS substitutes to the external resources, like images.
  2. Review the certificate information of the custom SSL certificate that you’re adding to CDN/Origin server and make sure all the information is correct and current. Things to check: intermediate certificates (check entire range  separately ), Private key, empty lines (delete if you encounter any).
  3. Use some reputable tool that can help generate an intermediate certificate.

Outdated Browser, Cache and Cookies

Older browsers may be unable to recognize the SSL-enabled sites because they don’t support these technologies. If browsers cache has saved the older SSL information about your site’s recently-updated certificate, then this message appears due to an info mismatch.

This error may still occur after you solve the problem. resolving the problem if that problem. The simple remedy is to clear your cache so your browser can again retrieve and read the updated certificate details.

Apache Issues

Apache Issues - Plesk

For Apache issues, you need to use codes. Digicert, leading SSL authority, provides a complete guide on how to resolve such issues. Along with solution codes that you might just need to copy/paste. With Digicert, you can also diagnose your SSL issues here, provide your site name and check for the reports.

Further DIY Solutions to HTTPS Issues in Plesk

If you love DIY exercises, then here are different ways to buy, manage or renew your SSL certificate in Plesk. All you have to do is to click the links below and follow the easy instructions.

  1. Change the default certificate
  2. Renew the default certificate
  3. Purchase SSL Certificate from Plesk
  4. Enable redirection from HTTP to HTTPS in Plesk
  5. Download SSL certificate in Plesk

This article presented some tricky errors along with their easy, DIY solutions. Let us know in the comments if we’ve managed to keep the instructions clear and simple and if you performed all the steps accurately.

arrow icon - Plesk

Cloudflare Releases New Warp VPN

Cloudflare releases new Warp VPN - Plesk Partners

Cloudflare has just launched their new Warp VPN which secures and optimizes DNS queries. Once enabled, Warp encrypts all connections – Securing all internet traffic on any device. Have a look at this VPN performance tool and what it can do.

Warp Protects Your Phone’s Traffic

Warp is able to run on any web browsers and app running on your phone. Cloudflare built the VPN around a UPD-based protocol optimized for mobile internet and the speed it requires. Thanks to Cloudflare’s massive global network, Warp VPN can connect with servers faster than ever.

In addition, tests show that Cloudflare’s network is constantly checking connections. So Warp improves Internet performance and delivers a better experience for users

“Tests show better internet speed once Warp is enabled” - says

vpn/" target="_blank" rel="nofollow noopener noreferrer">Cloudflare Chief Executive.

Warp Performance & Speed

Security is the main feature of VPN tools that impact Internet speed. However, Warp VPN not only improves security aspects but also Internet performance and reliability.

Cloudflare will launch two different versions of their New Warp VPN. The free, basic version is available to you now. But for better performance and speed, Cloudflare’s developing Warp+, the premium version for those wanting to work at lightspeed.


More Protection with ServerShield by Cloudflare

Admins and site owners know as well as we do that Server security is just as important as performance. So if you’ve already installed Plesk, we suggest looking into the free, complete security solution: ServerShield.

The extension will enable you to protect your websites against online threats and DDoS Attacks. Thus, stopping malicious web traffic while delivering content much faster. ServerShield provides a Web Application Firewall that can stop real-time attacks. This makes it easy to fight SQL injections, spam and cross-site scripting. For additional security features that harden your protection shields further, go for the Cloudflare ServerShield Plus Advanced option.

For more info, see the ServerShield installation guide.

Varnish for WordPress in a Docker container

Is your website experiencing heavy traffic? Are you looking for a solution that will reduce server load and will improve website speed? Varnish might just be what you need. Varnish listens for duplicate requests and provides a cached version of your website pages, mediating between your users’ requests and your server.

So how do you activate Varnish? In this article, I will show you how you can easily increase your website speed by using Varnish as a one click Docker container. I will demonstrate how using a website caching solution like Varnish can easily improve both page response times and the maximum number of concurrent visitors on your website. To simulate real traffic and measure correct response times, I have used an external server similar to, or to generate lots of traffic and concurrent users to our site.

What is Varnish and why should you use it?

Varnish Cache Plugin

Varnish HTTP Cache is a software that helps reduce the load on your server by caching the output of the request into the virtual memory. It is a so-called HTTP accelerator and is focused on HTTP only. Varnish is open source and is used by high traffic websites such as Wikipedia.

If you have lots of daily visitors, we recommend using a cache mechanism. You’ll see your response time improving significantly because the server can send the already cached data, directly from the memory, back to the client, without the resource consuming process handling on the web server. Additionally, it reduces the load on the CPU so that the server is able to handle many more requests without getting overloaded. I will demonstrate this in the stress tests later.

Running Varnish in a Docker container

Docker is a great open source project that makes it incredibly simple to add Varnish to a running server. We don’t need to install Varnish on the production server, we simply use a ready-to-go Varnish Docker image. The main advantage is that if something goes wrong with the container, we can simply remove it and spin-up a new container within seconds. The way in which Docker containers are designed guarantees that Varnish will always run independently of our system environment. Do you want to know more about Docker containers? Read more about the 6 essentials on Docker containers!

For this tutorial, I will use the newly integrated Docker support on Plesk to activate Varnish. The Plesk interface makes it easy to get a Varnish instance running, only requiring small modifications of the Varnish configuration file to be done using the terminal.

A further improvement would be to rebuild the Varnish Docker image so that it takes our configuration as a parameter from the Plesk UI. For now, I’ll stick to the original Docker image and upload our configuration via shell.

Activate Varnish in Plesk and test on a static page

Okay, let’s try it first on the default static page of Plesk. In the default settings, Plesk uses Nginx as a reverse proxy server for Apache. This means that Nginx is listening to default port 80(443 for HTTPS) and Apache to an internal port (7080 HTTP, 7081 HTTPS) We will push our Varnish container in between of the two web servers. In this scenario, Varnish will get the request from Nginx and the content from Apache. Don’t worry, it’s easier than it sounds!

Go to Docker and search for the image million12/varnish in the Docker Image Catalog. Once found, click “run” and Plesk will download the image to your local machine. After the download, click “run (local)”, which will open the configuration page of the container. The only thing that we’ll change is the port mapping.

Port mapping in Varnish
Varnish in Docker container on Plesk Onyx – Port mapping

Remove the tick at the option “Automatic port mapping” and set an external port (I will use port 32780 in this tutorial) for the option “Manual mapping”. This means that port 80 of the container is mapped to the external port 32780. By adding a proxy rule we can “talk” to the container through this external port. We will set the backend server in Varnish to the Apache port from where the data will be gathered if a “cache miss” occurred.

Test Varnish with a static page

Create a subdomain for testing our Varnish integration on a static page. After the subdomain was created, go to the “Hosting Settings” and deactivate the options “SSL/TLS support” and “Permanent SEO-safe 301 redirect from HTTP to HTTPS” because we want to test the Varnish functionality over HTTP first. Okay, but how do we redirect the requests to the Varnish container? This can be done easily with the option Docker Proxy Rules that you will find in the domain overview.

Proxy rules related to Varnish Cache
Varnish – Proxy rules for Docker container on Plesk Onyx

Click on “Add Rule” and select the previously created container and the port mapping that we entered manually. If you cannot make a selection, then your container is not running. In this case you should click on Docker in the menu and start the container first. If you open the subdomain after you’ve activated the proxy rule, you will see the error Error 503 Backend fetch failed. Don’t panic, this is an expected behavior. We did not configure the Varnish backend server yet!

Error 503 - Backend fetch failed
Varnish – Error 503 Backend fetch failed

Configure Varnish properly in the Docker container using SSH

This is the only time when we need to access the server and the Varnish Docker container via SSH. Open your terminal and type

$ ssh [email protected] // Replace with your user name and correct IP address

Enter your password if required to get access to the server. Tip: use a private / public key pair to improve the security of your server!

First of all, we need to find out the ID of our Docker container. To list all active container type into the command line

$ docker ps
Varnish HTTP Cache - Running Docker containers - Plesk Onyx
Varnish – Running Docker containers – Plesk Onyx

Copy the Docker ID and use the following command to access the Docker container

$ docker exec -it ID bash // Replace ID with the correct container ID

Okay, the most important thing to do is change the host and port value for the default backend server in the file. /etc/varnish/default.vcl

For .host we will enter the IP address of the server where Plesk is executed (in our example 111.222.333.444) and for .port 7080. As mentioned before, this is the default Apache HTTP port in Plesk. We have to use this port because, internally ,Varnish can only speak over an unencrypted channel!

Tip: Do we have a cache hit or miss?

How do we see that the content was loaded from the memory and not from the Apache server? You will see that the request was processed by Varnish through a special header entry in the response, you will not know whether the data was loaded from the memory or was requested from the Apache server.

To achieve it without having to use varnishlog in the console, we can set another header value with the corresponding value (cache hit / cache miss). We have to use the function sub vcl_deliver that is the last exit point for almost all code paths (except vcl_pipe). Add the following code within the curly brackets of the function sub vcl_deliver

if (obj.hits > 0) {
     set resp.http.X-Cache = "HIT";
} else {
     set resp.http.X-Cache = "MISS";

Use the Developer Tools in your browser to examine the response

Save the modified file and exit the container. Switch to your Plesk UI again and restart the container in Docker with the “Restart” button. When you see the success message, go to the tab of the subdomain with the 503 error message. Do not reload the page yet but open the Developer Tools first (alt + cmd + i on a MacBook). Go to the “Network” tab and reload the page. Select the first entry (URL /) and take a closer look at the “Response headers”.

Cache Miss and Varnish
Varnish – Cache Miss

If everything was done properly, you will see some new header variables:

X-Cache – This is the variable that I’ve defined in the configuration file. After the first reload it should display a “MISS”.
X-Varnish: ID – The internal ID for this file in Varnish {more information required}
Via: "1.1 varnish-v4" – This shows that the request was redirected through the Varnish container.

Okay, it’s about time to see some Varnish magic! Click on the reload button in your browser to reload the page. This time it will be loaded from the virtual memory.

Varnish - Cache Hit
Varnish – Cache Hit

What about websites that are using HTTPS to encrypt the connection?

It also works and the best part of it is that you don’t have to change anything! Create an SSL certificate for the subdomain using the great Let’s encrypt extension. After the certificate was created and assigned (the extension does it automatically), go the the static page and reload it using https:// instead of http:// If you open your browser console, you will see a X-Cache: HIT in the response headers:

Activate Varnish caching on your WordPress website

We just saw that it’s technically possible to activate Varnish inside a Docker container with Plesk. Now let’s try it on a WordPress website!

The main difference is the configuration of the VLC configuration file within the Varnish container. WordPress is a dynamic CMS, thus we cannot cache everything without restricting the functionality of the system; the administration pages shouldn’t be cached since changes wouldn’t be possible any more for logged in users.

There are many pre-defined configuration files for WordPress available on the internet, from various developers. In most cases, you can use them right away without any modifications. For our test integration, we will take the configuration file created by HTPC Guides (with small adjustments – link below).

For this article and for the stress tests I’ve created a fully workable website with WordPress. I want to test under real conditions and not with a default WordPress installation. The website should also be secured with an SSL certificate and only callable over HTTPS. For this reason, I will also activate an SSL certificate with the help of the Let’s Encrypt extension for this installation.

Use a WordPress Plugin to activate support for HTTPS

Important: Do not use the option “Permanent SEO-safe 301 redirect from HTTP to HTTPS” within Plesk in “Hosting Settings” because this will lead to a redirect loop in our special environment constellation. Instead I will use a WordPress plugin to switch our installation completely to HTTPS. The name of the plugin is Really Simple SSL and can be downloaded from the official plugin repository.

Please make the same preparations like for the static page but add this time the additional required configuration data for WordPress to the default.vcl configuration file inside the Docker container. I’ve used the this Varnish configuration file (GitHub Gist) for my test installation. Don’t forget to adjust the backend server again like we already did for the static page!

Tip: Do not forget to restart the Docker container from the Plesk UI to reload the configuration information. If you forget to restart the container, then Varnish will not work properly with the WordPress website.

Now reload the front page of WordPress with the browser console open. The first loading process should throw an X-Cache: MISS but the second (and following) reloads will return an X-Cache: HIT.

Cache Hit with Varnish HTTP Cache plugin
Varnish in WordPress – Cache Hit

Let’s run some stress tests with!

We’ve seen that Varnish helps to improve the performance of the website. What is with the promised load reduction on the CPU? I can test it with the so-called stress testing which will load the website with many concurrent users per second for a certain time span. Without any security and overload protection, the server will start to respond steadily slower until the requests cannot be handled any more completely. With activated Varnish the server will be able to serve such intensive requests longer without throwing errors.

All right, it’s time to run load and performance tests with the external service provider

Note: I used a very small server for this test instance (only 1 CPU and 500MB Memory), so the positive impact of Varnish should be much higher on a more powerful server!

Result WITHOUT Varnish:

Wordpress without Varnish HTTP Cache
Stress test – WordPress without Varnish

As you can see, I had to abort the stress test because the server already couldn’t handle the request after less than 5 seconds and less than 50 concurrent users. After just 15 seconds the server collapsed completely and no requests could be managed any more!

Result WITH Varnish:

Varnish HTTP cache - WordPress with Varnish
Stress test – WordPress with Varnish

Varnish magic! As you can see, the Varnish cache allows us to keep the server stable even under heavy load. The small test server handled over 300 concurrent users and responded all requests over 30 seconds without any errors. After 30 seconds and over 300 concurrent users the server was overloaded and couldn’t accept further requests. With a more powerful server the numbers should be much higher! So, it’s also great to keep your website reactively if it suffers a DDoS attack, at least for a certain number of requests.

Summary: Varnish for WordPress within a Docker container on Plesk

Let me make a small checklist:

  • Varnish in Docker container? Yes.
  • Varnish in WordPress? Yes.
  • Varnish in Plesk? Yes.
  • Varnish for WordPress within Docker container in Plesk? Absolutely, yes!

Mission accomplished! 🙂

As you’ve seen, Varnish can greatly improve the performance of your WordPress website and reduce the CPU-load of your server. It’s relatively easy to setup a working environment using Varnish in a Docker container between Nginx and Apache within Plesk. The most important part is the correct configuration of Varnish for your specific CMS.

Thank you for reading. In the next blog post, I will take a look into another memory caching system, Memcached.

Stay tuned and stay Plesky!

Google PageSpeed Insights – How to optimize your site to rank higher

So, you have a well-configured server but the performance of your website is poor. Your page response times (latency) are in the seconds and your server cannot handle more than 100 concurrent users. You’ve invested in SEO but you still feel that Google Search does not give you the ranking your site deserves. What do you do? How can Google PageSpeed Insights help you? Let’s start with the basics!

Performance is an important ranking factor

Good website performance is essential. A modern website does not just consist of some few static files, it is made up of front-end libraries and frameworks like Bootstrap. The more files a client has to download to render a complete page, the longer it’ll take a page to load. And the longer it takes for a page to load, the lower the ranking falls.

The impact of mobile

The other factor that is key to a website’s search ranking is its mobile-friendliness. Not only because mobile-friendly sites are optimized to load quickly on low throughput and high latency mobile connections, they also provide great user experiences.

A very popular framework to implement easily a responsive web design is Bootstrap, and even though Bootstrap is easy to use, it requires at least two more static files to be able to work. This means that we’re buying usability at the expense of loading performance. But don’t worry, I will explain how you can compensate for this small loss later in this article.

Google PageSpeed Insights helps to increase the performance

With PageSpeed Insights by Google, you can perform checks to identify areas of improvement and make your websites faster and more mobile-friendly within seconds – Both of which are key to get a pole position on Google Search.

Google PageSpeed Insights - Frontpage

You can use PageSpeed Insights for free from the project page, or follow our guide to install Google PageSpeed Insights Plesk Extension on your Plesk control panel.

Understanding PageSpeed Insights Recommendations

1. Avoid landing page redirects

Redirects can cause a perceptible latency if the request is redirected several times to the end point from where data is eventually sent to the client. Every redirect initiates another HTTP request-response action (with possible DNS lookups and TCP handshakes) which can dramatically decrease the site performance, especially on a mobile device with a slow internet connection.

A good example how to avoid redirects for mobile devices, is to use a modern, responsive design. An already mobile-optimized website does not require redirects to a dedicated subdomain for mobile devices.

Also make sure you redirect correctly in one step from to People tend to just type the shortest form of your domain to the browser address bar – but your website should run with https only (for more security and better ranking) and most probably use www as subdomain.

SEO tip: 301 redirects from HTTP to HTTPS

HTTPS has become an important factor for the ranking in Google. Search engine prefers website that use the HTTPS protocol to ensure secure communications between the two endpoints, here the client and the server. Consider activating a 301 redirect option in on your domains once you’ve installed your SSL certificates.

For Plesk users, the Plesk extension Security Advisor will help you to activate free certificates for all you websites, and you can activate your 301 redirects through “Hosting Settings” on your dashboard.

Talking about redirects, Plesk supports the SEO-friendly 301 redirects from HTTP to HTTPS out of the box. This means, if you activate a free SSL certificate powered by Let’s Encrypt, Plesk will help you to switch to the secure protocol without losing the ranking power.

2. Enable compression

Always send content compressed with GZIP or Deflate to the client. This rule checks whether the source served compressible resources (such as HTML, images or JS / CSS files) with compression. Compression reduces the number of bytes transferred over the network up to 90%. This reduces the overall time to download all resources which leads to a faster loading time and better user experience.

Important for the compression usage is that both sides (both client and server) understand the applied compression algorithm. The so-called HTTP Header fields exchange the supported algorithms. If you want the know more about the network protocol HTTP, then please read my article about HTTP/2. Most modern browsers do already support compression out of the box. On the server-side you can use special modules, e.g. mod_deflate (Apache) or ngx_http_gzip_module (Nginx).

Plesk supports compression out of the box

Don’t worry, a Plesk server already pre-installs the required compression modules, you just have to activate this feature manually for all domains that should use compression. You can add the needed code into an .htaccess (Apache) or web.config (NGINX) in the root directory of your website or even easier directly in Plesk:

Go to “Websites & Domains” and select “Apache & nginx Settings”. If you use the Apache web server, then you will have to add the following code into the textarea under “Additional Apache directives”. Select the textarea “Additional directives for HTTPS” if you are using HTTPS else the first textarea.


AddOutputFilterByType DEFLATE text/plain text/html text/xml;
AddOutputFilterByType DEFLATE text/css text/javascript;
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml;
AddOutputFilterByType DEFLATE application/rss+xml;
AddOutputFilterByType DEFLATE application/javascript application/x-javascript

If you use NGINX, then you have to add the following code into the text area “Additional nginx directives”.


gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_disable "msie6";
gzip_types text/plain text/css text/javascript text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss;

Warning: The dynamic compression can affect the CPU in the way that you could lose the performance advantage of the compression due to long CPU processing. It does not make sense to set the compression level to the highest level because the gain in the file size is minimal compared to an average level but the CPU load and processing time is dramatically higher. Another improvement would be to cache already compressed files and deliver them directly without any compression processes involved.

3. Leverage browser caching

The loading of static files is time-consuming and expensive. The browser stores already downloaded resources in the cache storage of the browser. The server can define a specific caching policy with special headers. The local cache should provide the resources from the local cache instead of requesting them again from the server.

You can use two header fields in the response header: Cache-Control and ETag. With  Cache-Control you can define how long the browser can cache individual responses. ETag creates a revalidation token with which the browser can recognize file changes easily.

The browser should cache static files for at least one week. If you have files that don’t change regularly or at all, then you can increase the cache time up to one year.

4. Reduce server response time

PageSpeed Insights triggers this rule if the server does not respond within a certain time span (>200ms). The response time means the time that the browser needs to load the HTML code for the output. Many factors can have a negative effect on the response time.

The reason of a slow response time is not easy to solve without insight analysis. Possible factors for the delay could be caused by the server, such as slow CPU or memory starvation, or in the application layer, e.g. slow script logic, heavy database queries or too many libraries included.

The question is, how to find those bottlenecks? You could use the New Relic Extension to solve such issues or alternatively check your website with WebPageTest to see how browsers render the pages and which files slow your site down!

5. Minify HTML, CSS & JavaScript

The server can minify resources like the HTML code or JavaScript and CSS files before sending them to the browser. This saves many bytes of data which speeds up the download of the resources. Minification is the process of compacting the code without losing any information that the client requires to render the website properly.

Such optimizations contain for instance the removing of comments, unused code or unneeded whitespaces. Don’t worry, you don’t have to do it manually, there are a lot of free tools or plugins that will do the job for you automatically. Just google it!

Note: If you look in such a minified file, you might think that this is not readable at all but for the computer it doesn’t make a difference. In fact, it is even better if the code is as compact as possible!

6. Eliminate render-blocking JavaScript and CSS in above-the-fold content

PageSpeed Insights triggers this rule if the browser loads JavaScript and CSS files even though the so-called above-the-fold content doesn’t need their code to create the proper output. This means that the browser can not render the HTML output as long as all external resources are not available completely.

An external resource is not necessarily a file from another server but an additional file in general that the client has to load on top the the HTML response to render the page properly. Rendering relevant JavaScript and CSS code can be added inlined. But this should be limited only to the absolutely necessary code parts. You should load not rendering critical JavaScript code asynchronously or deferred at the bottom of the page.

It also makes sense to concatenate all files into one single file (one file each for CSS and JavaScript) to reduce the amount of HTTP requests. In general, you should definitely activate HTTP/2 support on your server. The new version of the network protocol will have a very positive impact on the site performance. Read all about HTTP/2 and how to activate it in our blog post HTTP/2 – Increase your site performance!

7. Optimize images

If you have a lot of images on your website, then this could one of the biggest improvement potential. Optimizing images without an impact of the visual quality can reduce the file size significantly which in turn improves the download time and bandwidth usage drastically.

Many different possibilities exist to optimize images, e.g. resolution, image format or the quality settings. On many websites webmasters upload images in too high resolutions and thus with too large file sizes. PageSpeed Insights lists these files after the check with a percentage number of possible size saving for optimized variations of the same images.

Content-Delivery-Networks like CloudFlare (link to our extension) can optimize images automatically for you and bring them close to your customers. Be aware, this optimization feature requires a paid subscription. Of course, you can also optimize your images manually. Read this guide provided by Google: Optimize Images.

8. Prioritize visible content

This rule is similar to the render-blocking rule. PageSpeed Insights triggers it when additional network round trips are necessary to render the above-the-fold content of the loaded page. If visitors load this page over a slow connection (with high latencies), the additional network requests will create significant delays and degrade the user experience.

It is important to structure the HTML code that the critical content is loaded first. So, if you have a sidebar next to you article, then position the sidebar after the article in the HTML code so that the browser renders the article before the sidebar.

I’ve already mentioned the asynchronous JavaScript delivery, it is also possible to improve the CSS delivery strategy. Required CSS instructions in the visible content part can be loaded inlined directly in the HTML code and the rest deferred in one file after the rendering process.

Google PageSpeed Insights Plesk Extension

If you haven’t already done so, install the Google PageSpeed Insights Plesk Extension today and start improving your website performance and rankings.

Do you have tips of your own? Share them in the comments below.

Introducing Google PageSpeed Insights Plesk Extension

Google PageSpeed Insights Plesk Extension

Page performance is important for search engine rankings

Website performance is one of the things search engines look at to decide how to rank your page. Especially with the increasing number of visitors constrained by low throughput and high latency browsing on mobile devices, every second it takes to load a page matters.

What is Google PageSpeed Insights?

With PageSpeed Insights by Google you can perform checks to identify measurements to make your websites faster and more mobile-friendly within seconds. And this is also key to get a pole position in Google Search. The tool analyzes the delivered content of your website and makes suggestions to improve it.


Google PageSpeed Insights


You can use PageSpeed Insights for free from the project page. Enter your domain into the text field and click on the “ANALYZE” button. The service will review the entered URL and make some pre-defined performance rule checks to create an overall rating. The best score of 100 requires an optimized website that passes all performance rules successfully!

Read this article to find out how to use and understand Google PageSpeed Insights recommendations. 

Google PageSpeed Insights Plesk Extension

Google PageSpeed Insights Extension

Measuring website performance once isn’t enough. So we’ve created the Google PageSpeed Plesk Extension so you can quickly and directly run the checks regularly within Plesk – no more leaving the Plesk Interface and opening external pages to generate a detailed report.

The Google PageSpeed Plesk Extension not only gives administrators the rights to run a test, your customers or employees with normal user permission rights can also gain access to this extension. This is a great service feature for your customers if you are using Plesk as your control panel on your servers!

Main features of the Plesk extension

  • Check all your domains within seconds
  • Detailed report page with many improvement suggestions
  • Custom button to start check process and show ratings directly
  • Download optimized static files directly after the check
  • Store results and displays an overview page
  • For both administrators and end customers

Google PageSpeed Insights - Result page

If Google PageSpeed Insights can compress static files further, then the extension will show a download link to an archive with optimized files. Download the files and replace them on your web server (don’t forget to backup first) and improve the download performance for your visitors! This feature is also provided by Google.

Plesk Extension - Google PageSpeed Insights - Custom Button

Get your website performing even better today. Get the Google Pagespeed Insights Plesk extension here, or install it directly from your Plesk Extension Panel.

And don’t forget to read our article on how to use and understand Google PageSpeed Insights. 

Have fun optimizing your web projects and stay Plesky!