Current time: 12-05-2020, 07:32 PM Hello There, Guest! (LoginRegister)

Post Reply 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
TTFB & Page speed issue
06-03-2017, 04:18 PM
Post: #6
RE: TTFB & Page speed issue
(05-31-2017 12:16 AM)dfavor Wrote:  You're likely misunderstanding the point of CDNs.

As @pmeenan said, there's nothing your CDN can do to fix your HTML asset speed. shows this @ 2.5 secs.

Steps to fix.

1) Dump CloudFlare
(05-31-2017 12:16 AM)dfavor Wrote:  2) Dump NGINX (don't even think about it)
(05-31-2017 12:16 AM)dfavor Wrote:  3) Setup a LAMP stack using embedded PHP, likely a package like libapache2-mod-php7.1 for Ubuntu + Debian.
Nope. Run in fpm mode for both better resource use and simplification of monitoring
(05-31-2017 12:16 AM)dfavor Wrote:  4) Tune your LAMP Stack, which include tuning SSL.
Well, LEMP, but yup. Headers, too...
(05-31-2017 12:16 AM)dfavor Wrote:  CloudFlare fails to set Strict Transport Security. Fixing this allows HTTP2 to start faster, for subsequent page visits.
There's very little point in tuning your site if you're proxying it through cloudflare. You'll not see any change.
(05-31-2017 12:16 AM)dfavor Wrote: is a client site I host. This is a good example of the speed you're looking for serving the HTML asset - 158ms vs. your 2.5ms.
There's something a bit weird about this, as nothing then happens until 0.5s, and the start render time is about 3 seconds. Even though you're using http2, I'd still cut down on the number of resources: 116 is a bit large... combine css, and only load the fonts you actually use??
(05-31-2017 12:16 AM)dfavor Wrote:  CDNs should never cache HTML assets as they can change, so a correctly tooled CDN should never cache your HTML component... so all visitors can see any changes instantly.

This means, only LAMP tuning + also site tooling determine your HTML asset generation + serving speed.
Well the most important part of that is caching, which is only peripherally covered by tuning.
(05-31-2017 12:16 AM)dfavor Wrote:  Since you're running WordPress, the process for tuning sites is well defined... Just find a tuning guide + get started.

BTW, a correct tuning guide will start at the bottom of the LAMP stack, so a correct/useful guide will start with items like...

1) use ext4 file system + mount options noatime, dioread_nolock.
Nope. The whole point is to use the disks as little as possible, so any choice in file system will make a trivial change
(05-31-2017 12:16 AM)dfavor Wrote:  2) move /tmp off disk into memory (tmpfs)
Nope. PHP doesn't necessarily use /tmp at all. You need the caching and session resources tobe in tmpfs ( and of course you need enough spare memory to run it... bugger all use if it's in swap )
(05-31-2017 12:16 AM)dfavor Wrote:  3) verify your PHP Opcache runtime stats (I target 50% free memory keys + memory segments)
Well, more exactly, constantly monitor them so you can proactively modify required resources.
(05-31-2017 12:16 AM)dfavor Wrote:  4) periodically run mysqltuner + mysql-tuning-primer + fix whatever they say to fix
Would help if you understood the information you passed to you... for example if your query cache scaling properly?
(05-31-2017 12:16 AM)dfavor Wrote:  5) enable SAVEQUERIES in your wp-config.php file + check Query Monitor plugin output each time you make a code change + avoid themes/plugins producing excessive database thrash, like the Marketer's Delight theme (122 SELECTs to generate a page) or ACF (which can generate 100s-1000s of SELECTs if incorrectly used).
Too simplistic. I have plenty of WP ( and even worse, Magento ) servers running in the thousands of qps and delivering acceptable performance. It's all down to properly caching MySQL.
(05-31-2017 12:16 AM)dfavor Wrote:  So tune your LAMP Stack + tune your WordPress code, then look to external sites you're referencing which is also adding a huge amount of time to your page renders.

If you must access external sites, then do so via Javascript, after your PageLoad or DocumentReady event has fired (depends on what you're trying to accomplish).

You've missed off a few things from your list:
- choice of Database: Percona ( Mariadb uses that ), Oracle, ( 5.5 ), 5.6, 5.7, MyISAM, InnoDB, replication?, effect of backup strategy...
- post processing: pagespeed for example?
- static zipping of compressible resources
- use of lazy load and fpc plugins
- correctly sizing your server ( memory for database, cpu power for PHP )

But right at the top, if you're seriously looking for performance, you have to monitor your server, and the resources it uses. This allows you to be proactive with your changes, and more importantly to know how your platform is doing.
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: TTFB & Page speed issue - pmeenan - 05-30-2017, 11:08 PM
RE: TTFB & Page speed issue - pmeenan - 05-30-2017, 11:32 PM
RE: TTFB & Page speed issue - dfavor - 05-31-2017, 12:16 AM
RE: TTFB & Page speed issue - GreenGecko - 06-03-2017 04:18 PM
RE: TTFB & Page speed issue - pmeenan - 05-31-2017, 12:49 AM
RE: TTFB & Page speed issue - dfavor - 06-10-2017, 08:38 AM
RE: TTFB & Page speed issue - GreenGecko - 06-10-2017, 04:00 PM
RE: TTFB & Page speed issue - datadiggers - 06-26-2017, 06:29 PM
RE: TTFB & Page speed issue - GreenGecko - 06-27-2017, 03:48 PM
RE: TTFB & Page speed issue - datadiggers - 06-27-2017, 04:36 PM
RE: TTFB & Page speed issue - GreenGecko - 06-28-2017, 04:59 PM
RE: TTFB & Page speed issue - dfavor - 07-07-2017, 12:03 AM
RE: TTFB & Page speed issue - diesel2 - 07-27-2017, 02:50 AM
RE: TTFB & Page speed issue - GreenGecko - 07-27-2017, 11:33 AM
RE: TTFB & Page speed issue - diesel2 - 08-18-2017, 02:37 AM

Forum Jump:

User(s) browsing this thread: 1 Guest(s)