Understand and Fix Google Blocklist Warnings.

Caleb Lane – Firewall Analyst

Hi, thanks for the introduction, Val. Welcome everyone to the webinar. Before we get started, I want to just go over a few things and then the main topics we’ll cover on today’s webinar. The first thing being the two main metrics that you should be focusing on when optimizing your site for the best performance. The next part will be the steps that you should take to effectively optimize your site for the best performance and lastly, the tools and solutions to accomplish that.

To start, before you start to optimize your site for the best performance, I generally recommend establishing a baseline for your site. That way, you have results from before you optimize a site once you’re done to see how effective and how much your site improved from a performance perspective once you are done.

The two tools that I personally use the most for doing this are the Pingdom Website Speed Test Tool as well as our own tool, the Sucuri Global Performance Test Tool. Pingdom’s testing tool I prefer because it gives you a waterfall. If you’re not familiar with what a waterfall is, it’s basically a list of all of the requests for a site. The CSS, JavaScript, HTML, images, external requests, any other type of request, and it gives a breakdown of how long that request takes to load and it also includes additional metrics such as the page load size and different breakdowns of that, and various other metrics that are helpful.

The second tool, the Sucuri Global Performance Testing Tool gives you three metrics from a lot of different locations around the world which is helpful when establishing that initial baseline as well. I mentioned three other tools: Gtmetrix, WebPageTest, and Google Pagespeed Insights as well. I recommend trying all the tools and then picking the two or three that work best for you in what you’re trying to accomplish.

When optimizing your site for the best performance, generally people focus on the letter grade that these tools provide. I don’t recommend focusing on that as much. It’s definitely a factor that you should look at, but it’s not the main factor that I consider when optimizing a site for performance. One of the main reasons of that is it’s generic recommendations for all websites out there. What I mean by that is those are recommendations that are tailored for your site in a way that it is tailored, but at the end, it’s still generic recommendations apply to all sites and not individually for your site. It’s an automated check. Having a good understanding of performance and understanding a waterfall and different things, and the most important aspects of optimizing your performance are definitely a lot better than relying on that letter grade.

The two main metrics that I focus on when optimizing sites for performance are the page load size, so that’s the total kilo or megabytes that it takes for that site to load for a visitor. Then the number of requests, and that’s all of the requests that are mad out by the CSS, JavaScript, images, and other requests like that.

Before you start optimizing your site for performance, I recommend going through and doing a spring cleaning, similar to what you would do in your house in the spring, just go through and clean everything top to bottom. That’s what I recommend doing with your site as well.

First, before you get started, you want to make sure you take a full back up of your files and database. That way if anything goes wrong while you’re doing this, you have a back up to go to and you don’t have to worry about losing any data or having any issues. The other thing that I’ll mention is ideally you’re doing this in a staging or development environment and you’re not doing this in a production environment. So if something does go wrong, it’s not impacting your production site and it’s only on a staging or a testing site.

The next part is updating the content management system version you’re using whether that’s WordPress, [inaudible 00:09:04], Magento, whatever it may be, and also the plugins and themes. Updating everything often it contains security fixes and maintenance fixes along with new features. It also has the security benefits that as well, because it often patches those security vulnerabilities as I mentioned.

The next part, going hand in hand, you just updated everything on your application, you’ll also want to do that on the server. Depending on who your hosting provider is and how that is configured will depend on who’s responsible for this. If you’re on a server managed plan, then you’ll still want to reach out to your hosting provider and make sure that they are indeed keeping everything up to date because some hosting providers do fall behind on this. If you are managing the server yourself or paying a developer or system administrator to do that for you, you’ll definitely want to make sure that you’re doing that yourself because that responsibility falls on you.

The next part is removing any inactive plugins or themes. Generally a habit that we see a lot is that if you aren’t using a plugin or theme, you may just deactivate it and leave it on your site. If you aren’t using it, remove it because that way it can’t be used as a possible attack vector when a potential attacker is trying to compromise your website, and it also can’t impact the performance as well because it’s totally removed. If you ever do need it later down the road, you can always reinstall it.

Continuing on with spring cleaning, you don’t want to have any backups on the server. Anything that isn’t needed for your production site to perform and function as it should. Often, for example, backups, generally having backups and storing them on the same server as your production environment is never good practice anyway because if something goes wrong on that production environment, well your backups are on the same server, thus you can’t rely on those normally because they will be impacted as well.

The next part is having one purpose and one site per server. What I mean by that is you don’t want to have what’s commonly referred to as a soup kitchen server of having all of yours sites, e-mail, and every single possible function that you can think of, on the server because it not only hurts the performance but it also generally introduces security risks in your environment as well. Ideally, you want to have one site per server and if you have a lot of sites that’s generally not scalable or possible and if that’s the case, make sure you isolate them properly so that one can’t impact the other.

What we commonly see is sites continue to get reinfected through something that we refer to as cross-site contamination. What that means is if one site is on the server and it’s compromised and the other sites on the sever aren’t properly isolated from that site, it can cause that one site to impact all the other sites and all the sites on the server get infected.

The next part is removing old subdomains, domains, anything that isn’t being used. You’ve had a server for a few years, you’ve probably had a few websites on it over time. You aren’t using one of those sites, remove it. If it’s outdated and you still are using it, you should update it. Then the next thing is you don’t want to use a production server as a development or staging server. As I mentioned when ideally optimizing your site for performance, you don’t want to do this on the production environment, the same thing goes with isolating the development and staging server from the production server. That’s just good development practice as well.

The last part here goes hand in hand with keeping backups of the site or server on the same server that your production environment is. You don’t need to store personal files or any files that aren’t needed for the production site to function. There’s a lot better ways to store backups and personal files than production server.

The next part here is talking about hosting providers. This kind of goes with building a house. If you have a bad foundation to start, generally, that house is going to run into problems right away or, if not right away, down the road. The same thing goes with hosting providers. If you have a good hosting provider, that goes a long way in ensuring that it’s a reliable site that, generally, is more secure and performs in loads faster. There’s different ways that you can go about approaching what hosting provider to go with. There’s not one size fits all and it’s just something that you have to consider for your needs.

The first, it’s not as common an example, but if you’re a technical user and you had the skills, the time, and the availability to manage your server yourself, that’s definitely something you can consider. Keep in mind of that availability part I mentioned. Your server goes down at 3AM and you’re sleeping, are you going to get up from that text or that phone call and fix a server? If it’s a personal blog, maybe it can wait until the morning. But if it’s an eCommerce site, then you most likely can’t afford that downtime and that’s something that you have to consider if you’re going to consider going that route.

The next part is if you don’t have the time or expertise to manage the server yourself, you can always pay a developer or system administrator to do that for you. The same thing goes in saying that that’s the person that you’re going to be counting on if your site or server goes down, so make sure that they will be available and respond within the time limits that you need them to.

Lastly, the most common option is going with a managed hosting provider who will manage that server for you and if there are issues, the responsibility falls on them from the server aspect of that. You also have to keep in mind with managed hosting providers of the support they offer. Do they offer the type of support you prefer in terms of chat, phone support, e-mail support, ticket support, whatever it may be. Also if you need a certain SLA, your service level response time, are they offering that? Also you have to consider hours. Are they 24/7, 365 and is that you what need? Or can you manage to deal with a hosting provider that may only offer limited support on weekends, for example. For over 90% of people, managed hosting provider is the best fit but you can consider those two other options as well.

For themes, generally the best way to go about approaching a theme is going with a well coded framework and then hiring a developer to customize that for your design needs. The reason that this is best is because you have a solid foundation, it’s kind of the same thing with the hosting provider. From there you can pay a developer to customize the CSS, PHP, and any other programming language that you may need to fit it and make it unique for what you’re trying to accomplish with your business.

Some people, with a theme, try to go with a completely custom theme, but I generally don’t recommend that and it’s generally not the best approach for the large majority of sites and businesses out there. The reason being for that is it generally increases the development time and cost, it will complicate updating it as once that initial design is done, it’ll make it more complex to keep it up to date. For example, if that relationship ever ended with your developer or agency who did that theme originally, it can make it very difficult for a new developer agency to go in and keep that updated. It also, since you’re not having a dedicated person or a team like you might with framework keep that up to date, it is more likely to have performance issues or security vulnerabilities as a general rule of thumb.

If you have the time and you have the knowledge with CSS, PHP, to customize the theme yourself, that’s definitely something you can consider. Keep in mind though, if you aren’t very comfortable with PHP, you can very easily introduce vulnerabilities into your environment with insecure PHP code. That’s just something to keep in mind if you go that route.

Lastly, a common questions up of how would I find a developer to help customize that framework that I decided on for my site? What I recommend first is reaching out to the people you know, your colleagues, your friends, and seeing who they have to recommend. If multiple people are recommending the same person, it’s generally a good sign. You can reach out to those people that they recommend and those developers and engage with them to see if they fit the needs of what you’re trying to accomplish for your site and business.

The next part is plugins. Going back to the spring cleaning part I referenced earlier, if you don’t need a plugin, it’s best to delete it, not just deactivate it. The next part is plugins don’t come in one size. For example, with the WordPress repository, there are many WordPress plugins out there that can add social media buttons to your site, so Facebook, Twitter, the other major social networks, but they’re all not created equally. Some plugin authors, if you check the WordPress forum for any users who have opened up support tickets will reply very quickly, they’ll follow through to the end, if it’s a bug they’ll release a patch if it is a bug in the plugin. They’ll keep it regularly up to date, they’ll add new features, they’ll patch any security vulnerabilities that are discovered, and things like that.

Also, code comes in a lot of different shapes and sizes. If you’re not a developer, it’s often hard to evaluate a plugin’s code effectively. But if you are, I definitely recommend briefly taking a look at any plugins you’re considering’s code as well to get an idea of how secure and efficient it may be in those types of things. A lot of plugins have multiple features they offer, so for example, very popular WordPress plugin, Jetpack, has many different modules or features for it. It offers, within its settings, to go in and disable the modules that you aren’t using. If you’re only using five of the modules that Jetpack offers, I recommend going and disabling all those other modules. You’ll notice that it won’t impact your performance and the load time of your site as much if you do that. Same goes for other plugins as well.

The last part here being only use the necessary amount of plugins you do. One example is say you are trying to center the logo in the header of your site. Now, a lot of people would approach this of trying to add a plugin to accomplish while, in almost all cases, this could be very easily done with a few lines of CSS that you would add to your theme’s custom CSS file. That’s the route I would recommend going verse adding a plugin to accomplish something simple like that.

The next part is optimizing images. The first tool here is by TinyPNG. It gives a good idea of if you compressed all your images on a page, how much that would reduce the page load size of. It’s definitely something I recommend doing, just to give you an idea of how much page load size you can save by optimizing your images. Now I’ve tried a lot of the different image compression tools on the market, and there are definitely a lot. When I’ve tested them, the four tools or solutions I recommend depending on what CMS you’re using or what way you’re trying to compress the images, whether it’s through a web interface, a plugin, API, things like that, are TinyPNG image, Imagify, Kraken, and Optimus. I recommend you check out each one and pick the one that works best for you.

Continuing on with optimizing images, resizing images to scale. To give you an example of what I mean by that, say for example you have an image on your site that is 1000 by 1000 pixels. But when a visitor goes to it, the actual image size that’s displayed on your site is 500 by 500 pixels. In reality, that full image size of 1000 by 1000 pixel is still loading in the background adding unnecessary page load size to the total page load size for your site and generally being resized using HTML. The best way to go about this is resizing that image to scale and then reuploading it to be 500 by 500 pixels to save on that total page load size for your site. GTmetrix has a great section on this where it will provide any image that you can resize and the direct exact dimensions you should resize them to.

The next part here being using the correct image format. What I mean by that is there’s several different image formats out there, JPG, PNGs, and just making sure if you’re designing an image, for example in PhotoShop, that you’re using not only the best image type from a visual standpoint, but also from a standpoint of performance and that it’s the smallest and most efficient image type possible for the image that you are designing.

The next part is a newer web or image format that was actually invented by Google is WebP. It’s not supported by all major browsers yet, Safari and Internet Explorer should add support for it I imagine pretty shortly. You can still convert your PNG and JPG images to WebP image format to save on that total page load size. Optimus, which is a tool that I recommended to compress images on the previous slide, offers an option to convert your images to the WebP image format. It’s definitely something I recommend doing, especially if you have a lot of images in your site.

The last part here of compressing images is using CSS sprites. An example of this would be say you have five social media buttons in the top right hand header of your site, Twitter, Facebook, Instagram, Pinterest, things like that. Instead of those five images loading, you can use what’s called a CSS sprite with a few lines of CSS so that instead of having five images, you would have one image and the CSS would basically clarify the dimensions within that one image of the image that you need for what that social media button is. You would save four requests and just add a few lines of CSS to accomplish that. That’s definitely something that you can consider doing.

Some other areas to focus on when optimizing your site for performance, the first one being external requests. An external request is any request that doesn’t load directly from your site or server. To clarify in a little bit more detail here, a common example of this is ads. Another example is analytics, so Google analytics and the other analytic solutions out there. With external requests, it is a little bit, generally, more difficult to optimize these requests as you don’t have total control over these. One thing you can do is if the request isn’t absolutely necessary, you can remove it. A better option is, for example, say if it’s JavaScript, you can load it asynchronously, that way when it’s loading in the background, it’s not blocking other requests from loading. Then if those two aren’t options and you need that request to load, and it is causing a significant impact on your page load time, it’s generally best to reach out to your developer to see if there are any ways to optimize that external request to make it as efficient as possible.

The next part here is compression. GZip compression has been around for a long time and I recommend enabling it on your site if you aren’t using GZip compression. It’s a great way to reduce the page load size and it’s something that’s generally very easy to implement. There’s a newer type of compression called Guetzli compression which was also created by Google. It’s not supported by all major browsers and, in my testing, it’s definitely better than GZip compression. But since it isn’t supported by all the major browsers yet, if you don’t implement it exactly right, it can cause some conflicts. Be aware of that if you are going to consider using it before all the major browsers have support for it.

the next part here is HTTP/2. This is a newer protocol that was supposed to help with basically from HTTP/1.1 and it will impact any request loading over HTTPS. If you aren’t sure if you’re using HTTP/2, I recommend reaching out to your hosting provider and if they do offer it, make sure you have it enabled. If they don’t, encourage them to add it as a feature because it does have many performance benefits for HTTPS.

The next part here being minification. If you aren’t familiar with what minification is, it simply removes the white spaces and unnecessary characters and other things from, typically, your CSS and JavaScript. If you’re using GZip compression already, the amount of benefit that minification will have is generally smaller. But if you have the opportunity to implement it, it’s definitely something you can do but I wouldn’t go out of your way to implement it if you’re already using GZip compression. It can have a little bit more of a benefit with decreasing that page load size.

The next part here is concatenating static files. What that means is, typically, you take all of your CSS and, say, for example, you have 10 CSS files to load for all one URL on your site or one page. What concatenation would do is it would combine those 10 CSS files into one or two CSS files and the same thing applies with JavaScript. It would reduce the amount of total requests for your site. This can have a positive performance impact, but if you are using HTTPS and HTTP/2, it can make the benefits that the HTTP/2 protocol that it’s set out for kind of negligible. Concatenation is a workaround to some of the performance, basically lack of performance, how the HTTP/1.1 protocol was designed. Keep that in mind if you’re using HTTPS and HTTP/2, you most likely shouldn’t implement it. I always recommend with performance, though, testing it for your site and seeing what performs best because it does vary per site and per configuration as every site is very different.

The next part here is domain sharding. What that means is if you’re using what’s called a content delivery network, which we’ll talk a little bit more in detail in a few slides here, you will typically load your CSS, JavaScript, and your static files through a subdomain such as CDN.example.com. What domain sharding would do is it would add additional subdomains for those static files such as CDN1.example.com, et cetera. This was a more popular performance tactic and benefit a few years ago, it’s become less popular generally within the past few years. It’s something you can implement, but typically, it’s not necessary for the little benefit it provides. It’s definitely something if you are using a content delivery network, you should check in and consider doing because it could have a performance benefit depending on your configuration.

The next part here is generally when website owners are experiencing performance issues, their first inclination or approach is to upgrade the hosting plan or add more resources being CPU and RAM to their server. Generally, that’s not the approach that I recommend starting with. Generally, what I recommend doing is optimizing your application and server as much as possible. If you’re still having hosting issues and performance issues at that point, then you might consider looking at upgrading your plan or adding more resources to your server. That’s generally not the best approach starting out with.

The next part here is upgrading PHP. If you’re using an older version of PHP such as PHP 5.3 or 5.4, you should reach out to your hosting provider and see if they offer a more recent version of PHP such as 5.6 or PHP 7. They have many performance benefits that the older versions of PHP didn’t provide and they also have other benefits as well. If your hosting provider supports those, then as long as your application and any plugins, extensions, things like that, support that newer version of PHP as well, you should definitely look into upgrading that.

The next thing is enabling Keep Alive. What Keep Alive does is that any time a request is loaded through your site, there’s what’s called a handshake that is necessary on the networking end for that request to basically go through. What Keep Alive does is instead of having that handshake for every single request, it will use the first handshake for all the subsequent requests saving on the amount of handshakes for your site. It goes back to the principle of doing the same amount of things with, basically, less time. It’s definitely something you should implement and it’s generally something that’s very easily can be done in most configurations.

The next thing is fixing or removing 404 Not Found errors. If you’re not familiar with what a 404 response code is, it simply means that that request or file was not able to be found or it’s not a valid path for that file. If that file path is referencing the wrong file path and you just need to update that, then you should update that in your code if need be. But, if that file is no longer needed for your site, you should remove that reference in the code because your page load time will basically decrease as a result of doing that.

The next part here is fixing multiple redirects. As an example for this, say you have a CSS file and its loading over WWW and you’re forcing HTTPS on the site. But in the code, you’re referencing the naked root domain and HTTP instead of HTTPS. The browser, when that visitor goes to the site, is going to have to follow that redirect twice before it gets to that end result of HTTPS and WWW. You should always put the URL in the code that it ends up being, that way the browser doesn’t have to follow multiple redirects. Just increasing that page loading time for unnecessary reason.

The last parts here of some other areas to focus on are a general good rule of thumb is putting the CSS in the header of the site and the JavaScript in the footer of the site. For some features on your site, you may have to put some JavaScript in the header of your site. If that is the case, you’ll want to make sure you load that JavaScript asynchronously, that way it’s not blocking other request as it’s loading.

The next part here being lazy loading images. What that means is say, for example, you have 100 images on your site but when a visitor goes and loads your site, only 10 images are within the screen or visual view of that screen for that visitor. What lazy loading images would do is it would only load those 10 images initially and then as that user scrolls down and more images come within view visually for that visitor, it would load those images but not until then. If you had a lot of images on your site, it can be beneficial for your performance. But if you just have an average amount of images, it’s generally not something that would be necessary to implement.

The last part being here is a WordPress plugin called Query Monitor. It’s generally geared more towards technical users or developers, but it has various statistics and things such as it will give you the time to execute different database queries and it will point out the database queries that are taking longer and that way you can look into optimizing those. If you do use WordPress and you are more of a technical user, it’s definitely a plugin that you can at least check out when you’re optimizing your site for performance.

Now when talking about performance as a whole, I focused on those other areas at first because those areas aren’t often as talked about while they are still very beneficial and key parts when optimizing your site for performance. Now, the two, I would say most talked about, ways to optimizing your site for performance are caching and content delivery networks. They’re often referred to as CDMs. Basically, what caching and content delivery networks accomplish is they generally reduce the overall load on the host server and they also make the page load faster for the visitor.

There’s several different types of caching. The first one is a content delivery network. To give you an example of what a content delivery network is, say for example your site is hosted on one server in Arizona, but you have a majority of your visitors in Europe. Regardless where the visitor comes in the world, they’re still going to be routed to that one server in Arizona since that’s the only server where your site’s hosted. With a content delivery network, it will generally have what’s called multiple points of presence or servers located around the world in a lot of different continents and areas. That way a visitor in Europe would hit one of the points of presence or servers in Europe instead of the server in Arizona where your site’s hosted, thus reducing the page load time for that visitor.

The second type of caching is what I would call server caching. An example of this is something called varnish that are common setup is, for example, you have Apache but you’re running NGINX. In front of Apache is a reverse proxy and using that for caching. There’s a lot of different server configurations and caching options out there, that’s just two examples.

The last part here is instead of caching out on the server itself, you’re caching it on the application so more at the content management system. There’s a lot of plugins out there for the variety of content management systems with application caching and that’s the third type of caching.

When considering your different options out there for caching and content delivery networks, keep in mind that it’s generally always a good idea to use caching and a CDN. But there is a point in time that comes where it’s just redundant meaning that if you have too many layers of caching or if you have several content delivery networks, the benefit is really marginal at that point verse just using one caching method or two caching methods and one CDN verse using, say, all three caching methods and all two content delivery networks. It also generally complicates trouble shooting, makes the process of updating your site more difficult and things like that.

Now, the question is how does the Sucuri firewall integrate and help with the performance of your site? The first thing is we have what’s called a Global Anycast Network. Right now we have the six points of presence, three in the United States, two in Europe, and one in Japan. That operates as a content delivery network, that way the visitors request is routed to the closest server to them, helping reduce the latency and help with the performance of your site. The next part is caching. We have caching in place also with those different points of presence on our Global Anycast Network. If we have that request cached already, we can return that request directly to the visitor from our cache. That way we don’t even have to send a request to your host server, thus reducing the load on your host server as well as speeding up that page load time for your visitor.

The next two options here are compression and HTTP/2. These are both options within our interface that you can enable with just a simple click and it’s Gzip compression, HTTP/2, we talked about those earlier in the other areas that you should focus on when optimizing your site for the best performance. If you use our firewall, I definitely recommending you enable those features if you haven’t already.

Here is just a list of resources that I referenced in the webinar that you can refer back to. Again, as Val mentioned at the beginning of the webinar, you will get a copy of these slides a few days down the road here. That’s it for on my side of what I wanted to cover for optimizing your site for the best performance. Thanks for taking the time to listen and I will pass it now back over to Val so we can answer some of the questions you guys had.

I want to thank everyone for joining us. This is a really exciting period for us to sit down and chat with you on a number of security topics. I want to specifically start on what happens once an attacker is successful, and I think this is an important way to start. I think often we focus too much energy on what are the things we should be doing, but we don’t necessarily know what it is we’re trying to achieve. So a common theme you hear in my conversation – it’s all about mindset.