wordpress优化

According to Builtwith.com, WordPress holds close to 50% of the CMS share of the world’s top 1,000,000 websites. As for the ecommerce sphere, we’re at 33% with WooCommerce. And if we cast a wider net, percentages go higher. Although we may complain that WordPress can get bloated, resource-heavy, and its data model leaves a lot to be desired, there is no denying that WordPress is everywhere.

根据Builtwith.com的数据 ，WordPress 拥有 CMS在全球前1,000,000个顶级网站中近50％的份额。 至于电子商务领域，WooCommerce占33％。 如果我们投放更大的净额，则百分比会更高。 尽管我们可能会抱怨WordPress会变得，肿，占用大量资源，并且其数据模型还有很多不足之处，但不可否认WordPress无处不在。

WordPress can thank its simplicity and a low barrier to entry for this pervasiveness. It’s easy to set up, and requires next to no technical knowledge. Hosting for WordPress can be found for as little as a couple of dollars per month, and the basic setup takes just a half hour of clicking. Free themes for WordPress are galore, some with included WYSIWYG page builders.

WordPress可以感谢它的简单性以及这种普及性的低进入门槛。 它很容易设置，几乎不需要任何技术知识。 WordPress的托管服务每月只需花费几美元，而基本设置仅需点击一个半小时。 WordPress的免费主题非常丰富，其中一些包含所见即所得的页面生成器。

Many look down on it, but in many ways we can thank WordPress for the growth of the internet and PHP, and many internet professionals have WP’s gentle learning curve to thank for their careers.

许多人看不起它，但是在许多方面，我们要感谢WordPress带来的Internet和PHP的增长，而且许多Internet专业人员都拥有WP的温柔学习曲线来感谢他们的职业。

But this ease of entry comes at a cost. Plenty of websites that proudly wear the WordPress badge were not done by professionals but by the cheapest developers. And often, it shows. Professional look and professional performance were afterthoughts.

但是这种容易进入是有代价的。 许多自豪地佩戴WordPress徽章的网站不是由专业人士完成的，而是由最便宜的开发人员完成的。 而且经常显示。 专业的外观和专业的表现是事后才想到的。

One of the main points of feedback the owner of an aspiring high-quality website will get from a grudging professional is that performance and a professional look and feel shouldn’t be afterthoughts. You can’t easily paint or stick them over a website. Professional websites should be premeditated.

一个有抱负的高品质网站的所有者会从一个苦苦追求的专业人士那里得到的主要反馈意见之一是，性能和专业的外观不应是事后才想到的。 您不能轻易在网站上绘画或粘贴它们。 专业网站应该是有预谋的。

A famous UK used car dealer, Ling’s Cars, tried a unique way to make a kitsch marketing punchline. Unless you’re REALLY sure about what you’re doing, DO NOT try this at home.

英国著名的二手车经销商Ling's Cars尝试了一种独特的方式来制作媚俗的营销重点。 除非您真的确定自己在做什么，否则请勿在家中尝试。

And this starts with…

这始于…

选择主机 (Choice of Hosting)

Typically, new users will go with products that are on the low-cost side, with most of beginner-friendly bells and whistles. Considering the shady business practices by some big industry players in this arena, and the complaints and demands for site migration professionals coming from clients, this is a part of website setup that requires due attention.

通常，新用户会选择价格低廉的产品，以及大多数对初学者友好的产品。 考虑到一些大型行业参与者在此领域的阴暗商业行为 ，以及客户对网站迁移专业人员的抱怨和要求，这是网站设置的一部分，需要引起足够的重视。

We can divide WordPress hosting vendors into a few tiers.

我们可以将WordPress托管供应商分为几层。

Premium, WordPress-dedicated vendors like Kinsta whose plans start at $100 per month, or even higher-grade managed hosting like WordPress VIP by Automattic, may be worth their salt, but also may be out of reach for many website owners.

高端，WordPress专用的供应商(例如Kinsta，其计划起价为每月100美元)，甚至更高级别的托管主机(如Automattic的WordPress VIP) ，可能都值得一试，但对于许多网站所有者而言，这可能也是无法承受的。

Medium tier Flywheel, A2 hosting, Siteground and Pantheon are among those considered reliable and performance oriented, offering acceptable speed and a managed hosting service for those more price-conscious. Users here may get a bit less hand-holding, but these services usually strike an acceptable balance between a solid setup, price, and options for more advanced users. Not to forget, there is Cloudways, which is a hybrid between VPS and managed hosting. Those with their audience in Europe may look into Pilvia, as it offers a performant server stack and is pretty affordable.

中级Flywheel ， A2托管 ， Siteground和Pantheon属于可靠和性能导向的产品，它们为那些价格敏感的用户提供可接受的速度和托管托管服务。 这里的用户可能没有那么多手持设备，但是对于更高级的用户，这些服务通常在可靠的设置，价格和选项之间达到可接受的平衡。 别忘了， Cloudways是VPS和托管主机之间的混合体。 那些在欧洲听众的人可能会关注Pilvia ，因为它提供了高性能的服务器堆栈，而且价格合理。

There’s an interesting survey of customer satisfaction with more prominent hosting vendors, published by Codeinwp.

Codeinwp发布了一项有趣的调查，调查了一些比较著名的托管服务提供商的客户满意度。

For those of us not scared of the command line, there are VPS and dedicated-server vendors like Digital Ocean, Vultr, Linode, Amazon’s Lightsail, Hetzner in Europe, and OVH. Hetzner is a German vendor known for its quality physical servers on offer, somewhat above the price of virtual servers, while OVH offers very cost-efficient virtual servers. For the price-conscious, OVH’s subsidiary Kimsufi in Europe and Canada also offers bargain physical dedicated servers, and Host US has very affordable virtual servers.

对于我们这些不害怕命令行的，有VPS和专用服务器厂商如数字海洋 ， Vultr ， 的Linode ，亚马逊的Lightsail ， HETZNER在欧洲和OVH 。 Hetzner是一家德国供应商，以其提供的高质量物理服务器而闻名，该价格略高于虚拟服务器的价格，而OVH提供非常经济高效的虚拟服务器 。 出于价格意识，OVH在欧洲和加拿大的子公司Kimsufi还提供廉价的物理专用服务器，而Host US则提供了非常实惠的虚拟服务器。

With managed hosting, things to look for are a good server stack, good CDN integration, and of course SSD storage. Guaranteed resources, like with A2, are a big plus. The next thing to look for is SSH-access. Tech-savvy users may profit from WP-CLI availability.

使用托管托管，需要寻找的是良好的服务器堆栈 ，良好的CDN集成，当然还有SSD存储。 与A2一样 ，有保证的资源是一大优势。 接下来要寻找的是SSH访问。 精通技术的用户可能会从WP-CLI可用性中受益。

When choosing a VPS, the thing to look for is XEN or KVM virtualization over OpenVZ, because it mitigates the overselling of resources, helping guarantee that the resources you bought are really yours. It also provides better security.

选择VPS时，要寻找的是基于OpenVZ的XEN或KVM虚拟化，因为它可以减轻资源的过度销售，从而有助于确保您购买的资源确实是您的。 它还提供了更好的安全性。

Easy Engine is software that can make your entire VPS/WordPress installation a one-hour job.

Easy Engine是一款软件，可以使您整个VPS / WordPress的安装工作耗时一小时。

Regarding the server stack, Nginx is preferred to Apache if we’re pursuing performance, and PHP 7 is a must. If we really need Apache, using Nginx as a reverse proxy is a plus, but this setup can get complex.

关于服务器堆栈，如果我们追求性能，则Nginx优于Apache，而PHP 7是必须的。 如果我们确实需要Apache，那么最好使用Nginx作为反向代理，但是这种设置会变得很复杂。

Tests performed give PHP 7 a big edge over the previous version. According to fasthosts.co.uk:

经过测试， PHP 7比以前的版本更具优势。 根据fasthosts.co.uk ：

WordPress 4.1 executed 95% more requests per second on PHP 7 compared to PHP 5.6.

与PHP 5.6相比，WordPress 4.1在PHP 7上每秒执行的请求多95％。

When choosing your hosting, be aware of negative experiences with some providers that have become notorious.

选择托管服务时，请注意与一些臭名昭著的提供商的不良经历。

软件注意事项 (Software Considerations)

Things that usually slow down WordPress websites are bulky, bloated front ends with a lot of static resources and database queries. These issues arise from the choice of theme (and its page builders, huge sliders, etc) — which not only slow down initial loading due to many requests and overall size, but often slow down the browser due to a lot of JavaScript, and stuff to render, making it unresponsive.

通常会使WordPress网站变慢的事情是笨重的，前端肿的前端，其中包含大量静态资源和数据库查询。 这些问题是由主题(及其页面构建器，巨大的滑块等)的选择引起的–不仅由于许多请求和整体大小而减慢了初始加载速度，而且由于大量JavaScript和其他东西而常常使浏览器变慢渲染，使其无响应。

The golden rule here is: don’t use it unless there’s a good reason to.

这里的黄金法则是： 除非有充分的理由，否则不要使用它。

This may seem like a rule coming from the mouth of Homer Simpson, but if you can skip any of the bells and whistles, do so. Be conservative. If you must add some shiny functionality or JS eye candy, always prefer those tailored and coded as specifically as possible for your exact need. If you’re a skilled coder, and the project justifies the effort, code it yourself with minimalism in mind.

这似乎是从荷马·辛普森的口中得出的规则，但是如果您可以跳过任何风吹草动，请这样做。 保守一点。 如果您必须添加一些闪亮的功能或JS吸引眼球，请始终偏爱那些为满足您的确切需求而专门定制和编码的功能。 如果您是一名熟练的编码人员，并且项目证明了工作的合理性，请您自己编写代码，并牢记简约。

Review all the plugins your website can’t live without — and remove the others.

查看您的网站离不开的所有插件，然后删除其他插件。

And most importantly: back up your website before you begin pruning!

最重要的是： 在修剪之前，请备份您的网站！

资料模型 (Data model)

If you have a theme where you use a lot of custom posts or fields, be warned that a lot of these will slow down your database queries. Keep your data model as simple as possible, and if not, consider that WordPress’ original intended purpose was as a blogging engine. If you need a lot more than that, you may want to consider some of the MVC web frameworks out there that will give you greater control over your data model and the choice of database.

如果您有使用大量自定义帖子或字段的主题，请注意，其中很多都会减慢数据库查询的速度。 保持数据模型尽可能简单，如果没有，请考虑WordPress的最初目的是作为博客引擎。 如果您需要的还不止这些，则可能需要考虑一些MVC Web框架，这些框架将使您更好地控制数据模型和数据库选择。

In WordPress we can build a rich custom data model by using custom post types, custom taxonomies and custom fields, but be conscious of performance and complexity costs.

在WordPress中， 我们可以使用自定义帖子类型 ， 自定义分类法和自定义字段 来构建丰富的自定义数据模型，但要注意性能和复杂性成本。

If you know your way around the code, inspect your theme to find unnecessary database queries. Every individual database trip spends precious milliseconds in your TTFB, and megabytes of your server’s memory. Remember that secondary loops can be costly — so be warned when using widgets and plugins that show extra posts, like in sliders or widget areas. If you must use them, consider fetching all your posts in a single query, where it may otherwise slow down your website. There’s a GitHub repo for those not wanting to code from scratch.

如果您知道处理代码的方式，请检查主题以查找不必要的数据库查询。 每个单独的数据库行程都会在TTFB中花费宝贵的毫秒，以及服务器内存的兆字节。 请记住， 次级循环可能会很昂贵-在使用显示额外帖子的窗口小部件和插件时(例如在滑块或窗口小部件区域中)，请注意。 如果您必须使用它们，请考虑在一个查询中获取所有帖子，否则可能会降低您的网站速度。 有一个GitHub仓库供那些不想从头开始编写代码的人使用。

元查询可能会很昂贵 (Meta queries can be expensive)

Using custom fields to fetch posts by some criteria can be a great tool to develop sophisticated things with WP. This is an example of a meta query, and here you can find some elaboration on its costs. Summary: post meta wasn’t built for filtering, taxonomies were.

使用自定义字段按某些条件获取帖子可能是使用WP开发复杂事物的好工具。 这是元查询的示例， 在这里您可以找到有关其成本的详细说明。 简介： post meta不是为过滤而构建的，分类法则是 。

get_post_meta is a function typically called to fetch custom fields, and it can be called with just the post ID as an argument, in which case it fetches all the post’s meta fields in an array, or it can have a custom field’s name as a second argument, in which case it returns just the specified field.

get_post_meta 是通常用来获取自定义字段的函数 ，可以仅以帖子ID作为参数来调用它，在这种情况下，它将获取数组中所有帖子的元字段，或者可以将自定义字段的名称作为第二个参数，在这种情况下，它仅返回指定的字段。

If using get_post_meta()for a certain post multiple times on a single page or request (for multiple custom fields), be aware that this won’t incur extra cost, because the first time this function is called, all the post meta gets cached.

如果在单个页面或请求(针对多个自定义字段)上多次对某个帖子多次使用get_post_meta() ，请注意， 这不会产生额外的费用 ，因为第一次调用此函数时， 所有帖子元都会被缓存 。

数据库卫生 (Database hygiene)

Installing and deleting various plugins, and changing different themes over the lifetime of your website, often clutters your database with a lot of data that isn’t needed. It’s completely possible to discover — upon inspecting why a WordPress website is sluggish, or why it won’t even load, due to exhausted server memory — that the database has grown to hundreds and hundreds of megabytes, or over a gigabyte, with no content that explains it.

在网站的整个生命周期中，安装和删除各种插件以及更改不同的主题通常会使数据库中不必要的大量数据杂乱无章。 完全有可能发现-在检查WordPress网站为何呆滞或为什么由于服务器内存耗尽而无法加载时-数据库已增长到数百MB或超过1 GB，没有内容解释了这一点。

wp-options is where a lot of orphaned data usually gets left behind. This includes, but is not limited to, various transients (this post warns of best practices regarding deletion of transients in plugins). Transients are a form of cache, but as with any other caching, if misused, it can do more harm than good. If your server environment provides it, wp-cli has a command set dedicated to transients management, including deletion. If not, there are plugins in the WordPress plugins repo that can delete expired transients, but which offer less control.

wp-options通常会遗留大量孤立数据。 这包括但不限于各种瞬态 ( 此帖子警告有关删除插件中的瞬态的最佳实践)。 瞬态是缓存的一种形式，但是与任何其他缓存一样，如果滥用，则弊大于利。 如果您的服务器环境提供了它，则wp-cli具有专用于瞬态管理 (包括删除) 的命令集 。 如果不是，则WordPress插件存储库中有一些插件可以删除过期的瞬态，但提供的控制较少。

If deleting transients still leaves us with a bloated database without any tangible cause, WP-Sweep is an excellent free tool that can do the job of cleaning up the database. Another one to consider is WP Optimize.

如果删除暂态仍然使我们拥有庞大的数据库而没有任何明显的原因，那么WP-Sweep是一款出色的免费工具，可以完成清理数据库的工作。 另一个要考虑的是WP Optimize 。

Before doing any kind of database cleanup, it’s strongly recommended that you back up your database!

在进行任何类型的数据库清理之前，强烈建议您备份数据库！

One of the plugins that comes in very handy for profiling of the whole WordPress request lifecycle is Debug Objects. It offers an inspection of all the transients, shortcodes, classes, styles and scripts, templates loaded, db queries, and hooks.

对于整个WordPress请求生命周期进行概要分析非常方便的插件之一是Debug Objects 。 它检查所有瞬态，短代码，类，样式和脚本，已加载的模板，数据库查询和挂钩。

After ensuring a sane, performance-oriented setup — considering our server stack in advance, eliminating the possible bloat created by theme choice and plugins and widgets overload — we should try to identify bottlenecks.

在确保合理的，面向性能的设置之后-预先考虑我们的服务器堆栈，消除主题选择以及插件和小部件过载可能造成的膨胀-我们应该尝试确定瓶颈。

If we test our website in a tool like Pingdom Speed Test, we’ll get a waterfall chart of all the resources loaded in the request:

如果我们使用Pingdom Speed Test之类的工具测试我们的网站，我们将获得请求中加载的所有资源的瀑布图：

This gives us details about the request-response lifecycle, which we can analyze for bottlenecks. For instance:

这为我们提供了有关请求-响应生命周期的详细信息，我们可以对其进行分析以发现瓶颈。 例如：

• If the pink DNS time above is too big, it could mean we should consider caching our DNS records for a longer period. This is done by increasing the TTL setting in our domain management/registrar dashboard.

  如果上面的粉红色DNS时间过长，则可能意味着我们应该考虑将DNS记录缓存更长的时间。 这可以通过在我们的域管理/注册商信息中心中增加TTL设置来完成。

• If the SSL part is taking too long, we may want to consider enabling HTTP/2 to benefit from ALPN, adjusting our cache-control headers, and finally switching to a CDN service. “Web Performance in a Nutshell: HTTP/2, CDNs and Browser Caching” is a thorough article on this topic, as is “Analyzing HTTPS Performance Overhead” by KeyCDN.

  如果SSL部分花费的时间太长，我们可能要考虑启用HTTP / 2以从ALPN中受益，调整缓存控制标头，最后切换到CDN服务。 “ Web性能简而言之：HTTP / 2，CDN和浏览器缓存 ”是该主题的详尽文章，KeyCDN的“ 分析HTTPS性能开销 ”也是如此。

• Connect, Send, and Receive parts usually depend on network latency, so these can be improved by hosting close to your intended audience, making sure your host has a fast uplink, and using a CDN. For these items, you may want to consider a ping tool too (not to be confused with the Pingdom tools mentioned above), to make sure your server is responsive.

  Connect ， Send和Receive部分通常取决于网络延迟，因此可以通过在预期的目标受众附近托管，确保主机具有快速的上行链路并使用CDN来改善这些延迟。 对于这些项目，您可能还需要考虑使用ping工具 (不要与上面提到的Pingdom工具混淆)，以确保服务器能够响应。

• The Wait part — the yellow part of the waterfall — is the time your server infrastructure takes to produce or return the requested website. If this part takes too much time, you may want to return to our previous topics of optimizing the server, WordPress installation, and database stack. Or you may consider various layers of caching.

  等待部分(瀑布的黄色部分)是服务器基础结构用于生成或返回请求的网站所花费的时间。 如果这部分花费了太多时间，您可能需要返回之前的主题，以优化服务器，WordPress安装和数据库堆栈。 或者，您可以考虑各种缓存层。

To get a more extensive testing and hand-holding tips on improving the website, there’s a little command line utility called webcoach. In an environment with NodeJS and npm installed (like Homestead Improved), installing it is simple:

要获得有关改进网站的更广泛的测试和掌握技巧，有一个名为webcoach的命令行实用程序。 在安装了NodeJS和npm的环境中(例如Homestead Improvement )，安装起来很简单：

npm install webcoach -g

After it’s been installed, we can get detailed insights and advice on how to improve our website’s various aspects, including performance:

安装后，我们将获得有关如何改善网站各个方面(包括性能)的详细见解和建议：

快取 (Caching)

Caching can make all the difference when managing a WordPress website. There are a few layers and possible ways of caching.

在管理WordPress网站时，缓存可以发挥所有作用。 有一些缓存层和可能的方式。

页面缓存 (Page Caching)

Page caching is caching of the entire HTML output of a web application.

页面缓存是Web应用程序的整个HTML输出的缓存。

If we can, we should try to test the server-level solutions first, like NGINX caching, or Varnish, or caching systems offered by managed host vendors like Kinsta, Siteground, and others.

如果可以的话，我们应该首先尝试测试服务器级别的解决方案，例如NGINX缓存或Varnish，或托管主机供应商(例如Kinsta，Siteground等)提供的缓存系统。

If this doesn’t turn out to be as helpful as we’d like, we may want to consider plugins like WP Super Cache, WP Fastest Cache, or the overhauled W3 Total Cache from GitHub. All of these can improve performance, but usually require some experimenting. Badly configured caching solutions can actually harm the site’s performance. W3TC, for example — at least before the overhaul — is known to be maybe the best free caching solution, doing real wonders … when it works. When it doesn’t, it can take your website offline.

如果结果没有如我们所希望的那样有用，我们可能需要考虑使用WP Super Cache ， WP Fastest Cache或从GitHub全面检修的W3 Total Cache之类的插件。 所有这些都可以提高性能，但是通常需要进行一些实验。 配置错误的缓存解决方案实际上会损害站点的性能。 例如，至少在检修之前，W3TC可能是最好的免费缓存解决方案，它可以在工作时产生奇迹。 如果没有，它可以使您的网站离线。

WP Rocket is known to be maybe the most praised of the premium caching solutions.

WP Rocket可能是最受赞誉的高级缓存解决方案。

Page caching can improve performance drastically, serving entire websites from RAM, but be aware that it can introduce complications if you have a dynamic website with a cart, or parts that depend on cookies or a personalized front end. It can serve one user’s UI parts to another user, so it usually needs to be tested before being put into production. This especially applies to solutions on non-managed servers, like Varnish or Cloudflare page cache.

页面缓存可以极大地提高性能，可以通过RAM为整个网站提供服务，但是请注意，如果您有一个带有购物车的动态网站，或者依赖于Cookie或个性化前端的部件，那么页面缓存可能会带来一些麻烦。 它可以将一个用户的UI部件提供给另一用户，因此通常需要在投入生产之前对其进行测试。 这尤其适用于非托管服务器上的解决方案，例如Varnish或Cloudflare页面缓存。

片段缓存 (Fragment caching)

Fragment caching is a solution to think about when dynamic, cookie-dependent websites become hard to cache with a full-page approach, or when we are caching Ajax requests. A good introduction is available here.

片段缓存是一种解决方案，可以考虑以下问题：何时难以使用全页方法来缓存依赖Cookie的动态网站，或者何时缓存Ajax请求。 这里有一个很好的介绍。

对象缓存 (Object cache)

Object cache means compiling and storing in-memory all the database queries and PHP objects. Some caching plugins try to manage object-cache back ends for us. The back ends used are usually APCu, Memcached and Redis. They need to be installed on the server.

对象缓存意味着在数据库中编译和存储所有数据库查询和PHP对象。 一些缓存插件尝试为我们管理对象缓存后端。 使用的后端通常是APCu ，Memcached和Redis。 它们需要安装在服务器上 。

To go deeper into benchmarking our PHP code and the performance of our object caching, a valuable tool which requires shell access and wp-cli installed is the profile command. We can install it with:

为了更深入地测试我们PHP代码和对象缓存的性能， profile命令是一个需要外壳程序访问并安装wp-cli的有价值的工具。 我们可以通过以下方式安装它：

wp package install git@github.com:wp-cli/profile-command.git

or

要么

wp package install wp-cli/profile-command

(You may need to add the --allow-root flag, depending on the installation.)

(根据安装情况，您可能需要添加--allow-root标志。)

Then we can profile the whole load cycle, or drill down to specific hooks, files and classes, their load time and caching ratio.

然后，我们可以分析整个加载周期，或深入研究特定的挂钩，文件和类，它们的加载时间和缓存比率。

浏览器缓存 (Browser caching)

Browser caching means forcing visitors’ browsers to keep static files in their cache, so they don’t need to get them from our server on repeat visits. cache-control and expires headers are used here. Caching plugins often manage browser caching and setting the headers. Technumero made a guide that goes into more depth.

浏览器缓存意味着强制访问者的浏览器将静态文件保留在其缓存中，因此，他们无需在重复访问时从我们的服务器获取它们。 此处使用cache-control和expires标头。 缓存插件通常管理浏览器缓存和设置标头。 Technumero 制作了更深入的指南 。

静态文件 (Static Files)

Static files are images, stylesheets, JS code, fonts, media files, etc. We should make sure we compress them, and that we’re leveraging HTTP/2 to serve these files if possible. If our managed hosting doesn’t support HTTP/2, or moving our unmanaged VPS to HTTP/2 is out of reach, the easiest way is to implement a CDN into our stack. CDNs serve our static files from data centers closest to our audience. This decreases latency and usually means taking advantage of their highly tuned infrastructure.

静态文件是图像，样式表，JS代码，字体，媒体文件等。我们应该确保压缩它们，并在可能的情况下利用HTTP / 2来提供这些文件。 如果我们的托管主机不支持HTTP / 2，或者无法将非托管VPS迁移到HTTP / 2，最简单的方法是将CDN实施到堆栈中。 CDN从最接近我们的受众的数据中心提供我们的静态文件。 这减少了等待时间，通常意味着利用其高度调整的基础架构。

Autooptimize is one plugin that can help manipulate our static assets, and reduce the number of requests, concatenating JS and stylesheet files, minifying them and thus shrinking the page output.

Autooptimize是一个插件，可以帮助操纵我们的静态资产，并减少请求数量，连接JS和样式表文件，最小化它们并因此缩小页面输出。

Regarding media files, we should consider compressing/encoding our videos to reduce their size, and serving them through providers like YouTube, to reduce the strain on our servers. Cloud storage providers like Amazon S3 are another good option. Video hosting is out of scope of this article, but WPMUDEV made a handy guide about the topic.

关于媒体文件，我们应该考虑对视频进行压缩/编码以减小其大小，并通过YouTube之类的提供商进行提供，以减轻服务器的负担。 像Amazon S3这样的云存储提供商是另一个不错的选择。 视频托管不在本文讨论范围之内，但是WPMUDEV提供了有关该主题的便捷指南 。

Regarding images, these are often too big for the web. Sometimes the only solution that will allow our server to breathe — and might take a lengthy amount of time — is batch compression through the shell. Imagemagick on Linux has a useful convert tool that allows us to batch compress our images. This example does it recursively with all JPGs in a folder, reducing JPEG quality to 80%, along with other small enhancements, and resizing the images (it should be self-explanatory):

关于图像，这些图像通常对于网络而言太大。 有时，唯一允许我们的服务器喘气的方法(可能要花费很长的时间)是通过外壳进行批压缩。 Linux上的Imagemagick有一个有用的convert工具，使我们可以批量压缩图像。 本示例对文件夹中的所有JPG进行递归处理，将JPEG质量降低到80％，以及其他一些小的改进，并调整图像的大小(这应该是不言自明的)：

for file in *.jpg; do convert "${file}" -resize 20% -sharpen 3 -sharpen 2 -brightness-contrast "0x26" -quality 80 thumb."${file}"; done

WP Bullet has two excellent guides to batch compress JPG and PNG files.

WP Bullet有两个出色的指南，用于批量压缩JPG和PNG文件 。

Apart from that, there’s the Imagify service and the accompanying WordPress plugin to reduce image sizes, EWWW image optimizer, and others…

除此之外，还有Imagify服务和随附的WordPress插件以减小图像大小， EWWW图像优化器等。

其他随机提示 (Other random tips)

• Memory: make sure your installation has enough.

  内存 ： 确保您的安装足够 。

• XML-RPC and login page can often suffer from automated, scripted brute-force attacks — even if one isn’t a big fish. Even without breaking in, they can waste the CPU cycles. We should try to stop them on the server-level, before our WordPress installation is loaded. If we don’t need the access to xml-rpc.php, we can put this snippet inside our virtual host block on nginx:

  XML-RPC和登录页面通常会遭受脚本化的暴力自动攻击，即使这不是一条大鱼。 即使没有介入，它们也可能浪费CPU周期。 在加载WordPress安装之前，我们应尝试在服务器级别停止它们。 如果不需要访问xml-rpc.php ，可以将此代码段放在nginx上的虚拟主机块中：

  location = /xmlrpc.php {
  deny all;
  }

  In Apache:

  在Apache中：

  <Files xmlrpc.php>
  deny from all
  </Files>

  Plugins like iThemes Security, WPS Hide login and others can help with this and with changing our login page URL.

  诸如iThemes Security ， WPS Hide登录之类的插件以及其他插件可以帮助您更改登录页面URL。

  If you’re under brute force attacks and you aren’t protected by a CDN like Cloudflare — or a managed host’s protection — consider a firewall like fail2ban (you should probably have a firewall in place whether under attack or not).

  如果您受到暴力攻击，并且没有像Cloudflare这样的CDN或受托管主机的保护，则可以考虑使用fail2ban这样的防火墙(无论是否受到攻击，您都应该有适当的防火墙)。

• WordPress Heartbeat: polling the server while WordPress dashboard is open can slow your server, and make your dashboard unresponsive. Especially if it’s open in multiple browser tabs or by several users. The HeartBeat plugin can help solve that.

  WordPress心跳 ：在WordPress仪表板处于打开状态时轮询服务器会降低服务器速度，并使仪表板无响应。 尤其是在多个浏览器标签中或有多个用户打开的情况下。 HeartBeat插件可以帮助解决该问题。

• MAX_INPUT_VARS: when saving posts with lots of meta fields, or variable products with WooCommerce, we may reach a limit of maximum allowed request variables (variables sent by complex WooCommerce products can go into thousands). This can bring down your server. Here’s how to fix it.

  MAX_INPUT_VARS ：当使用WooCommerce保存带有很多元字段或变量产品的帖子时，我们可能会达到允许的最大请求变量限制(复杂的WooCommerce产品发送的变量可能达到数千个)。 这可以关闭您的服务器。 解决方法如下 。

• If your WordPress installation with a big database — especially a WooCommerce installation — starts having issues with speed that you can’t solve otherwise, consider ElasticPress. Some have had luck with it.

  如果具有大型数据库的WordPress安装(尤其是WooCommerce安装)开始出现速度问题，而您无法解决其他问题，请考虑使用ElasticPress 。 有些人对此很幸运。

• If you use WordFence, make sure to turn off the Live View feature. It can bring to a halt even a VPS with couple of gigabytes of memory.

  如果您使用WordFence，请确保关闭实时显示功能。 它甚至可以停止具有几GB内存的VPS。

• If you’re logging access to your website — particularly in debug.log in your wp-content directory — mind its size. It can grow to the level of gigabytes and crash your server.

  如果您要记录对网站的访问权限，尤其是在wp-content目录中的debug.log中，请注意其大小。 它可能会增长到千兆字节级别，并使服务器崩溃。

• If you have system crashes on your server/hosting, core dumps will fill up your storage. Have someone analyze the reasons of those crashes, and then delete those files. You’ll recognize them by patterns that look like core.XXXXXX.

  如果您的服务器/主机系统崩溃， 核心转储将填满您的存储。 让某人分析这些崩溃的原因，然后删除那些文件。 您将通过类似于core.XXXXXX 。

All this said, a repeat warning is in order: before you do any changes to your website, back it up!

所有这些都说明了一个重复的警告： 在对网站进行任何更改之前，请备份它！

结论 (Conclusion)

I hope this compilation of WordPress optimization tips will come in handy. As sites grow in size, the tricks are harder and harder to retroactively apply. That’s why it’s best to start early, and strive for a maximum effect: apply as many of these techniques before you launch, and you’ll not only have a smooth launch, but also a performant app from day 1 — surely a fantastic experience for all new users.

我希望此WordPress优化技巧汇编能派上用场。 随着网站规模的扩大，这些技巧越来越难以追溯。 这就是为什么最好尽早开始并争取最大的效果： 在启动之前应用许多这样的技术，不仅会顺利启动，而且从第一天起就具有性能出色的应用程序-对于所有新用户。

Make sure you also check out SitePoint’s PWA guide. Making your WP site as PWA as possible from day 0 will help users install it on the home screens of their devices, priming them for repeat visits.

确保您还查看了SitePoint的PWA指南 。 从第0天起，将您的WP网站尽可能地设置为PWA，将有助于用户将其安装在设备的主屏幕上，从而为重复访问做好准备。

翻译自: https://www.sitepoint.com/complete-guide-wordpress-performance-optimization/

wordpress优化