Page Speed Load Time Optimizations

Here are a few impor­tant ways to speed up page load­ing times, togeth­er with the improved record­ed times for com­par­i­son on a typ­i­cal Word­Press web site. While Word­Press is hard­ly an opti­mized web appli­ca­tion, it does ben­e­fit from the same speedup meth­ods as most web applications.

I used Google Chrome Devel­op­er Tools to time net­work trans­fers and page load times. There are var­i­ous web-based tools avail­able as well:

• https://developers.google.com/speed/pagespeed
• https://tools.pingdom.com
• https://www.webpagetest.org

Initial speed — 1.412 sec (TTFB 0.12 sec)

This was the speed on a fresh install of a Word­Press web site on a small VPS run­ning Nginx and PHP-FPM.

Enabling GZip compression — 1.326 sec (TTFB 0.13 sec)

Using com­pres­sion on net­work trans­fers can great­ly reduce file sizes, espe­cial­ly for text-based files such as HTML, CSS and JavaScript. The CPU over­head on mod­ern servers is neg­li­gi­ble, and can be cached if required.

PHP Opcode cache — 1.299 sec (TTFB 0.124 sec)

PHP scripts are typ­i­cal­ly com­piled to byte­code on demand. By caching this com­pli­ca­tion with OPcache or APC, page load times and serv­er load can be sig­nif­i­cant­ly reduced. APC did include a fast key/value cache, which has now been replaced by APCu.

WordPress Cache — 0.733 sec (TTFB 0.122 sec)

There are many Word­Press cache plu­g­ins avail­able, which reduce the amount of PHP code that has to be run on every request. Some caches can gen­er­ate flat files, which are sig­nif­i­cant­ly faster, and can be used with Nginx.

Nginx FastCGI Cache — 0.731 sec (TTFB 0.119 sec)

Nginx is able to use a fast memory/disk cache to cache requests to PHP-FPM, fur­ther reduc­ing page load times and serv­er loads. This can be very ben­e­fi­cial on web sites with high load.

There are many oth­er ways to speed up page load times, includ­ing depen­den­cy con­cate­na­tion and mini­fi­ca­tion and image opti­miza­tion. It is also impor­tant to opti­mize client-side JavaScript to allow the user’s web brows­er to dis­play con­tent quickly.

AnyCast DNS

An ini­tial vis­it to a web site requires a DNS lookup. Tra­di­tion­al­ly DNS has no way to send requests to the geo­graph­i­cal­ly clos­est serv­er, but this is pos­si­ble with Any­Cast DNS. This fea­ture is avail­able on many providers includ­ing Ama­zon’s Route 53, Google’s Cloud Plat­form and Microsoft Azure. It func­tions by allow­ing mul­ti­ple servers dis­trib­uted through­out the world to have the same IP address.

By using Any­Cast DNS, I was able to reduce an ini­tial DNS request from 93 mil­lisec­onds to 18 mil­lisec­onds. Com­bined with hav­ing an opti­mized web serv­er geo­graph­i­cal­ly close, even an ini­tial vis­it to a web page can be dis­played instantaneously.

Conclusion

Sub­tract­ing the round trip time to the serv­er of 0.116 sec­onds, these opti­miza­tions reduced the effec­tive Time To First Byte to 3 mil­lisec­onds. On a busy serv­er, these opti­miza­tions will make a sig­nif­i­cant dif­fer­ence to the capac­i­ty of the server.