很多人盲目地按照网络上的教程来对自己的WordPress网站进行优化，其实这种操作并不可取，我们需要对应的解决方法。
情景
首先，我们将WordPress分为前、后台（注：仅仅在本文的概念）。其实前后台对于WordPress这个程序而言，并不是太过严谨。毕竟该程序使用的是PHP，而PHP拥有渲染功能，这也是为什么PHP开发对于大多数人来说是非常容易的。这点可以看下JSP，PHP可能在某种方面和它非常像。
目前很多主题都是采用的这种制作方式，在PHP中嵌套html，让PHP来做前端渲染，而并非是前后端分离式。我所看到的有做前后端分离的主题应该有：「7B2」,其他的没咋看过，所以使用「7B2」主题的WordPress前台运行和渲染将会非常快，大部分数据交由后端处理后返回前端，然后让渲染前端，各司其职。
前台举例
我们举一个例子，如果我们的首页加载速度很慢，我们应该如何解决？
很多人都会想到使用这些插件，例如：「WP Rocket」、「WP Super Cache」。这两个插件的作用，如果用通俗的话来讲就是生成静态页面，供网友访问。但是有一个很大的缺点，如果你是登录用户又怎么办？当然，如果你的站点没有「登录/注册」功能那就另说。
匿名访客的网站体验非常好，但对登录用户不是友好，所以这就是一个弊端。
明白这一点后，我们继续来看。例如这里，我们的主题（并没有采用前后端分离）首页展示了所有的文章，而文章数量只有「10」，这时我们访问首页，体验感很好。
那么我们接着来，如果文章数量日积月累，文章数量变为了「10000」，甚至更多，这时我们再去访问首页，是否会感觉又一定的卡顿？
那么是什么引起的这个卡顿？先不考虑渲染，我们只是将文章的数据从数据库里去取出。那么，我们执行这个「SQL」查询一定会花费大量的时间，毕竟是「MySQL」。所以，分页在这里就起了很大的帮助。
这就是为什么，大部分主题都会采取分页的形式展示文章。
好的，那么我们来到首页渲染的话题。接着我们上文的情景，我们取出了相对应数据（未分页），然后将其展示在首页上，而PHP将会运行渲染这个页面。而渲染这个页面，将会花费大量的时间。如果我们使用了vue或者其他渲染数据的方法，这个情况便会将大幅度的改善。
所以从以上的分析我们可以得出结论，可以对首页的分页后每页的文章数量（SQL），以及渲染（PHP）出手。
SQL优化
对于「SQL」我们应该如何优化？WordPress给出了使用外部高级缓存的解决方法，这里我们就会遇到很多教程所说的使用：「Memcached」「Redis」等等。我们这里就聊聊「Memcached」，「Redis」主要还是多并发的场景。
这里我们给「Memcached」一个通俗的理解：将查询缓存拉入内存。我们都知道内存的处理速度是非常快的，而它主要占据的就是内存。通过将大部分的「SQL」查询加入内存缓存，达到加速查询的效果。例如我们调用首页的文章：第一次访问，「SQL」查询文章并输出；第二次，检测是否有相对应的查询缓存，如果存在，则从缓存中输出结果，如果没有，则再做一次「SQL」查询。
所以在我们启用「Memcached」后，并不会立刻生效，而是当访问者第二次访问首页才会生效。简单来说，首页响应想要快，就必须有人来第一次访问产生缓存，让后续的人访问变快。
所以，对于有访问量，并且有交互式功能的网站，启用「Memcached」是一个不错的选择。
后台举例
这里我先要提出一个问题，启用的插件越多，后台处理速度会越慢吗？相信看到这里的你，一定在其他网站上看到过这样的话语：插件启用的越多，WordPress速度就会变慢。在我看来，这种说法非常的绝对，也许只是站长自己推敲出来，或者说他的检错或者开发能力较弱。
首先我们来回答，为什么有些WordPress启用了插件后台访问速度就会变慢，甚至拖慢了前台页面的访问。
WordPress的插件有许多的功能，比如后台检测、扫描是否安全等等，并且WordPress官方也给出了很多钩子和过滤器，方便开发者开发功能。而插件的运行流程和功能，就成为了影响后台速度的主要因素。
例如我这里提供一个插件，有一个功能，检测后台是否全部「SSL」，并且要求「联网」。
接下来，我给出插件的大致运行流程：
- 访问指定URL，检测是否有更新
- 检测插件是否完整
- 访问后台URL，检测是否全部「SSL」
- 获取相关的WordPress版本信息
- 输出相关数据
那么各位看看，哪项流程会「大幅度」影响最后的输出速度呢？这里，我认为是：「1,(2),3」
访问指定URL，检测是否有更新
如果我们的目标URL无法访问，或者访问速度慢，就会造成这里的执行流程堵塞（注意：这里是单线程）。流程停留在「1」动不了，直到等待访问超时或者等待目标服务器做出响应。
这里就会浪费PHP的大量时间，所以你大概率就会看到页面一直加载。
检测插件是否完整
来到流程「2」，插件开始检测是否完整。这里如果我们在之前就为其设置了相应的「CRC」值，比对即可，但当插件的体积异常庞大，例如「1 GB」，这里就会造成访问等待，也会在页面反应出一直等待的情况。
访问后台URL，检测是否全部「SSL」
和流程「1」一样，只要是涉及到访问远程地址的，如果目标服务器响应慢，TTFB过长，都会导致PHP的运行时间增加，拖累后台速度。
后台优化
在知道我提出的插件是如何拖累后台速度，我们就可以相应的解决问题：
- 关闭插件更新
- 注释不必要的访问远程服务器的函数
- 注释不必要的检测
OK，那么到这里，我们解决了大部分的后台速度慢的问题
其他问题
其他的问题话，例如古登堡的问题，不过这个问题现在应该没有了，毕竟WordPress已经在尽全力做本土化，尽量降低TTFB，所以这里就不需要在考虑。
所以还是得看实际问题，不能盲目跟风，当然跟风误打误撞可能会对，也有可能更加严重。
