{"id":14856,"date":"2016-10-10T12:15:01","date_gmt":"2016-10-10T09:15:01","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=14856"},"modified":"2016-10-08T17:58:11","modified_gmt":"2016-10-08T14:58:11","slug":"pregenerating-static-web-pages-better-performance","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/","title":{"rendered":"Pregenerating Static Web Pages for Better Performance"},"content":{"rendered":"

In my recent Tuning NGINX<\/a> article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s article, we\u2019re going to put that in practice. Last time, we tuned our environment by adjusting parameters within NGINX. Now, we\u2019re going to explore a sometimes-overlooked aspect of tuning: making adjustments to how our application works.<\/p>\n

The application we will be tuning is a generic WordPress site that is built on a LEMP (Linux + NGINX + MySQL + PHP) stack. I selected WordPress because by default it dynamically generates every page, whether it\u2019s the front page of a blog that may not change often or specific articles that may receive comments daily.<\/p>\n

For each request made to a WordPress site, that site is served by NGINX, a PHP application, and MySQL. This means that every request is serviced by three different service layers.<\/p>\n

Pregenerating Semi-dynamic Pages<\/h2>\n

In order to increase our web application\u2019s performance, we\u2019ll be pregenerating the results of our \u201cdynamic\u201d pages and saving those results into a file cache. We will then configure NGINX to use the file cache for HTTP requests rather than our dynamic web application.<\/p>\n

The end result will be that every HTTP request will be serviced by only one service layer, which will have quite an impact on performance.<\/p>\n

Establishing a Baseline<\/h2>\n

Before making any changes, the first thing we should do is establish a baseline metric for application performance. In the previous article<\/a>, I used ApacheBench<\/a> to measure the number of requests per second that NGINX could service. We can use this same metric for our testing today as well.<\/p>\n

Let\u2019s see what happens if we run ab<\/code> against an existing WordPress installation I have already set up.<\/p>\n

$ ab -c 40 -n 1000 http:\/\/example.com\/\r\nConcurrency Level:      40\r\nTime taken for tests:   141.269 seconds\r\nComplete requests:      1000\r\nFailed requests:        0\r\nTotal transferred:      64731000 bytes\r\nHTML transferred:       64483000 bytes\r\nRequests per second:    7.08 [#\/sec] (mean)\r\nTime per request:       5650.762 [ms] (mean)\r\nTime per request:       141.269 [ms] (mean, across all concurrent requests)<\/pre>\n
Based on the output above, it appears that our baseline is 7.08<\/code> requests per second. At the moment, this web application is a vanilla WordPress installation without any performance plugins or tuning of the LEMP stack.<\/p>\n
Let\u2019s see how much of an improvement we\u2019ll get by pregenerating our front page.<\/p>\n
Creating a Cache<\/h2>\n
Even within WordPress, there are several ways to generate a file cache of dynamic content. For this article, I will be taking a simple, noninvasive approach. We\u2019ll simply request the page we wish to cache and save the results into a file.<\/p>\n
Create a store for our cache<\/h3>\n
Since we\u2019ll be creating a file-based cache, let\u2019s go ahead and create a directory within our application\u2019s root directory to retain cached files.<\/p>\n
# mkdir \/var\/www\/example.com\/htdocs\/cached<\/pre>\n
Within the htdocs<\/code> directory of our WordPress installation, we created a cached<\/code> directory. Within this directory, we are going to create our cache files. To generate those files, we will be using the curl<\/code> command.<\/p>\n
# curl -H 'host: example.com' http:\/\/192.168.33.10 > \/var\/www\/example.com\/htdocs\/cached\/index.html<\/pre>\n
The curl<\/code> command is a very powerful utility for working with web applications from the command line. Chances are, if you\u2019ve worked from the command line of a Linux\/Unix system, you have used curl<\/code> at some point.<\/p>\n
In the example above, the curl<\/code> command will be performing an HTTP GET request to http:\/\/192.168.33.10<\/code>. This address is the IP address of our example WordPress installation. In addition to the HTTP address in the command above, we are also using the -H<\/code> flag to set the host<\/code> header to a value of example.com<\/code>. This header is used by NGINX to determine how our request is routed and which content to display. By setting this to example.com<\/code>, we are ensuring that we are routed to our example site.<\/p>\n
At the end of the command above, you can see a ><\/code> used to redirect the output of the curl<\/code> command to \/var\/www\/example.com\/htdocs\/cached\/index.html<\/code>. This redirect will write the output of our HTTP request to the index.html<\/code> file.<\/p>\n
The output of our HTTP request is of course, the HTML generated when curl<\/code> requested our WordPress site\u2019s front page.<\/p>\n
Whether it\u2019s with curl<\/code> or a web browser such as Chrome, the contents of the index page for this WordPress site are always the same. At least, until a new article is posted. By saving the generated HTML to a file, we can tell NGINX to serve requests from our cached HTML file rather than sending the request to the PHP application on the backend.<\/p>\n
# chown -R www-data:www-data \/var\/www\/example.com\/htdocs\/cached<\/pre>\n
Before we move on to configuring NGINX, we first need to reset the ownership of our newly created cache file. So far, the commands we have run have been executed as the root<\/code> user. Which means that the file and directory we created are owned by the root<\/code> user. By resetting the owner to www-data<\/code>, we are ensuring that NGINX can read our cached file.<\/p>\n
Configure NGINX<\/h3>\n
Now that we have our cached file created, we need to tell NGINX to serve that cached file instead of the WordPress application. To do this, we\u2019ll be editing the \/etc\/nginx\/sites-enabled\/example.com<\/code> file. This file is the example.com<\/code> specific configuration file that defines how the example.com<\/code> site is served by NGINX.<\/p>\n
Let\u2019s take a look at the current contents.<\/p>\n
server {\r\n\r\n    server_name example.com   www.example.com;\r\n\r\n    access_log \/var\/log\/nginx\/example.com.access.log rt_cache;\r\n    error_log \/var\/log\/nginx\/example.com.error.log;\r\n\r\n    root \/var\/www\/example.com\/htdocs;\r\n\r\n    index index.php index.html index.htm;\r\n\r\n    include common\/php.conf;\r\n    include common\/wpcommon.conf;\r\n    include common\/locations.conf;\r\n    include \/var\/www\/example.com\/conf\/nginx\/*.conf;\r\n}<\/pre>\n
The above is fairly standard for a site running WordPress. To leverage our file cache, we will need to add to add a few items to the above configuration.<\/p>\n
location ~ ^\/$ {\r\n  try_files \/cached\/index.html \/index.php;\r\n}<\/pre>\n
While at first our additions may look a bit complex, they\u2019re actually pretty simple once you understand what they\u2019re doing.<\/p>\n
The first part, location<\/code>, is an NGINX directive that identifies the location of the HTTP request. If that request matches the ^\/$<\/code> regular expression, NGINX will apply the directives within the curly brackets. The ^\/$<\/code> regular expression will match any HTTP request that is targeting a location that begins and ends with \/<\/code>. Essentially this is the address for the WordPress front page (http:\/\/example.com\/).<\/p>\n
The second part, try_files<\/code>, is an NGINX directive that tells NGINX to look for the specified file (\/cached\/index.html<\/code>) and return the contents of that file rather than its normal processing. If for whatever reason it doesn\u2019t find that file, NGINX will route the request to the defined URI (\/index.php<\/code>).<\/p>\n
The fact that NGINX will redirect requests to \/index.php<\/code> if no cache file is found is very useful. If for some reason NGINX cannot find our cached file, the WordPress application would still serve content to visitors. Now that our changes have been added, let\u2019s take a look at the entire configuration again.<\/p>\n
server {\r\n\r\n    server_name example.com   www.example.com;\r\n\r\n    access_log \/var\/log\/nginx\/example.com.access.log rt_cache;\r\n    error_log \/var\/log\/nginx\/example.com.error.log;\r\n\r\n    root \/var\/www\/example.com\/htdocs;\r\n\r\n    location ~ ^\/$ {\r\n      try_files \/cached\/index.html \/index.php;\r\n    }\r\n\r\n    index index.php index.html index.htm;\r\n\r\n    include common\/php.conf;\r\n    include common\/wpcommon.conf;\r\n    include common\/locations.conf;\r\n    include \/var\/www\/example.com\/conf\/nginx\/*.conf;\r\n}<\/pre>\n
The location of these lines are somewhat arbitrary, however they should be added after the root<\/code> definition and before the includes<\/code>; the configurations being included<\/code> in this example may have some processing rules that would override our directive.<\/p>\n
With our changes made, we can apply them by issuing a reload<\/code> of NGINX. We can do this with the service<\/code> command.<\/p>\n
# service nginx reload<\/pre>\n
With the reload<\/code> complete, our configuration changes have now taken effect.<\/p>\n
Measuring the Results<\/h2>\n
With our modifications made, let\u2019s see how our performance has changed by rerunning the same test using the ab<\/code> command.<\/p>\n
$ ab -c 40 -n 1000 http:\/\/example.com\/\r\nConcurrency Level:      40\r\nTime taken for tests:   1.524 seconds\r\nComplete requests:      1000\r\nFailed requests:        0\r\nTotal transferred:      64783000 bytes\r\nHTML transferred:       64499000 bytes\r\nRequests per second:    656.10 [#\/sec] (mean)\r\nTime per request:       60.966 [ms] (mean)\r\nTime per request:       1.524 [ms] (mean, across all concurrent requests)<\/pre>\n
In the baseline test, our site was able to service 7.08<\/code> requests per second (mean). With the changes above, our site is now able to service 656.10<\/code> requests per second (mean). That is a performance increase of over 9000%<\/code>, and the only thing we did was pregenerate the content of our front page.<\/p>\n
Understanding the results<\/h3>\n
The resulting improvement may seem quite high; to better understand why the performance increased so much, let\u2019s break down how our HTTP requests were serviced before and how they are serviced now.<\/p>\n
With the vanilla WordPress installation, every HTTP request to \/<\/code> would be forwarded from NGINX to the php-fpm the application service used to serve PHP applications. Specifically, WordPress in this case. The WordPress application itself would then make several queries to the MySQL database. This transaction flow would occur for each and every HTTP request.<\/p>\n
With the above configuration changes added, now NGINX will first search for the \/cached\/index.html<\/code> file when an HTTP request is made to \/<\/code>. If it finds that file, it opens that file and returns the contents to the HTTP client.<\/p>\n
By having NGINX serve the content from cache, we save time and system resources with each request by eliminating the need to call php-fpm and MySQL. We are also playing to one of NGINX\u2019s strengths, as we saw in the previous NGINX tuning article; the NGINX service is very efficient at serving static content.<\/p>\n
In Conclusion<\/h2>\n
In this article, we set up our web server (NGINX) to look for and use a cached HTML file to answer HTTP requests. This resulted in a huge performance increase in our web application\u2019s response time. This improvement in performance does however come with some negatives.<\/p>\n
One of the negatives is that we have now removed the dynamic nature of our front page. For this site, it\u2019s okay because our front page is rarely updated. However when updates do happen, they will not automatically be seen by our visitors, which leads us to another negative. In order to ensure that visitors are seeing new content as soon as it\u2019s published, we must update the cache every time new content is published.<\/p>\n
With WordPress, this process is made easy thanks to caching plugins such as WP Total Cache<\/a> and WP Super Cache<\/a>. For non-WordPress web applications, this may require some customization, whether that customization is external to the web application like our curl<\/code> example or an internal function.<\/p>\n
The key to using this methodology is to understand just how dynamic each page needs to be and cache pages that can be cached, while selectively not caching pages that require dynamic content. I personally have found that after implementing a file-based cache within my web applications, I will often change the way I design my web applications to use caching more efficiently.<\/p>\n
One way I update design for cache efficiency is to try to use client-side dynamic content rather than server-side. An example of this is using the Disqus<\/a> comments plugin rather than WordPress\u2019 native comment system. This allows me to serve dynamic content while also leveraging the speed of file caches.<\/p>\n
Have a tip that makes it easier to create and manage caches? Share it by adding a comment to this article.<\/p>\n
\n\n\n\n
Reference: <\/span><\/td>\nPregenerating Static Web Pages for Better Performance<\/a> from our WCG partner<\/a>\u00a0Ben Cane at the Codeship Blog<\/a> blog.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s article, we\u2019re going to put that in practice. Last time, we tuned our environment by adjusting parameters within NGINX. Now, we\u2019re going to explore a sometimes-overlooked aspect of …<\/p>\n","protected":false},"author":158,"featured_media":927,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-14856","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development"],"yoast_head":"\nPregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026<\/title>\n<meta name=\"description\" content=\"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Pregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026\" \/>\n<meta property=\"og:description\" content=\"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\" \/>\n<meta property=\"og:site_name\" content=\"Web Code Geeks\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/webcodegeeks\" \/>\n<meta property=\"article:published_time\" content=\"2016-10-10T09:15:01+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"150\" \/>\n\t<meta property=\"og:image:height\" content=\"150\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Benjamin Cane\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@webcodegeeks\" \/>\n<meta name=\"twitter:site\" content=\"@webcodegeeks\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Benjamin Cane\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\"},\"author\":{\"name\":\"Benjamin Cane\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/4f5d918df9c19fab91b5b205357ce0b8\"},\"headline\":\"Pregenerating Static Web Pages for Better Performance\",\"datePublished\":\"2016-10-10T09:15:01+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\"},\"wordCount\":1681,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg\",\"articleSection\":[\"Web Dev\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\",\"url\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\",\"name\":\"Pregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026\",\"isPartOf\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg\",\"datePublished\":\"2016-10-10T09:15:01+00:00\",\"description\":\"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s\",\"breadcrumb\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage\",\"url\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg\",\"contentUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg\",\"width\":150,\"height\":150},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.webcodegeeks.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Web Dev\",\"item\":\"https:\/\/www.webcodegeeks.com\/category\/web-development\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Pregenerating Static Web Pages for Better Performance\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#website\",\"url\":\"https:\/\/www.webcodegeeks.com\/\",\"name\":\"Web Code Geeks\",\"description\":\"Web Developers Resource Center\",\"publisher\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.webcodegeeks.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\",\"name\":\"Exelixis Media P.C.\",\"url\":\"https:\/\/www.webcodegeeks.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png\",\"contentUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png\",\"width\":864,\"height\":246,\"caption\":\"Exelixis Media P.C.\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/webcodegeeks\",\"https:\/\/x.com\/webcodegeeks\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/4f5d918df9c19fab91b5b205357ce0b8\",\"name\":\"Benjamin Cane\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/09c6af2f1a7430456089189937094b817ef1b7c75ab9968bfd3ec35d938d914b?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/09c6af2f1a7430456089189937094b817ef1b7c75ab9968bfd3ec35d938d914b?s=96&d=mm&r=g\",\"caption\":\"Benjamin Cane\"},\"description\":\"Benjamin Cane is a systems architect in the financial services industry. He writes about Linux systems administration on his blog and has recently published his first book, Red Hat Enterprise Linux Troubleshooting Guide.\",\"url\":\"https:\/\/www.webcodegeeks.com\/author\/benjamin-cane\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Pregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026","description":"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/","og_locale":"en_US","og_type":"article","og_title":"Pregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026","og_description":"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s","og_url":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/","og_site_name":"Web Code Geeks","article_publisher":"https:\/\/www.facebook.com\/webcodegeeks","article_published_time":"2016-10-10T09:15:01+00:00","og_image":[{"width":150,"height":150,"url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg","type":"image\/jpeg"}],"author":"Benjamin Cane","twitter_card":"summary_large_image","twitter_creator":"@webcodegeeks","twitter_site":"@webcodegeeks","twitter_misc":{"Written by":"Benjamin Cane","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#article","isPartOf":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/"},"author":{"name":"Benjamin Cane","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/4f5d918df9c19fab91b5b205357ce0b8"},"headline":"Pregenerating Static Web Pages for Better Performance","datePublished":"2016-10-10T09:15:01+00:00","mainEntityOfPage":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/"},"wordCount":1681,"commentCount":0,"publisher":{"@id":"https:\/\/www.webcodegeeks.com\/#organization"},"image":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage"},"thumbnailUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg","articleSection":["Web Dev"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/","url":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/","name":"Pregenerating Static Web Pages for Better Performance - Web Code Geeks - 2026","isPartOf":{"@id":"https:\/\/www.webcodegeeks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage"},"image":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage"},"thumbnailUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg","datePublished":"2016-10-10T09:15:01+00:00","description":"In my recent Tuning NGINX article, I talked about how it\u2019s important to tune based on the specific needs of an application and its environment. In today\u2019s","breadcrumb":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#primaryimage","url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg","contentUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2014\/10\/web-dev-logo.jpg","width":150,"height":150},{"@type":"BreadcrumbList","@id":"https:\/\/www.webcodegeeks.com\/web-development\/pregenerating-static-web-pages-better-performance\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.webcodegeeks.com\/"},{"@type":"ListItem","position":2,"name":"Web Dev","item":"https:\/\/www.webcodegeeks.com\/category\/web-development\/"},{"@type":"ListItem","position":3,"name":"Pregenerating Static Web Pages for Better Performance"}]},{"@type":"WebSite","@id":"https:\/\/www.webcodegeeks.com\/#website","url":"https:\/\/www.webcodegeeks.com\/","name":"Web Code Geeks","description":"Web Developers Resource Center","publisher":{"@id":"https:\/\/www.webcodegeeks.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.webcodegeeks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.webcodegeeks.com\/#organization","name":"Exelixis Media P.C.","url":"https:\/\/www.webcodegeeks.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","contentUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","width":864,"height":246,"caption":"Exelixis Media P.C."},"image":{"@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/webcodegeeks","https:\/\/x.com\/webcodegeeks"]},{"@type":"Person","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/4f5d918df9c19fab91b5b205357ce0b8","name":"Benjamin Cane","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/09c6af2f1a7430456089189937094b817ef1b7c75ab9968bfd3ec35d938d914b?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/09c6af2f1a7430456089189937094b817ef1b7c75ab9968bfd3ec35d938d914b?s=96&d=mm&r=g","caption":"Benjamin Cane"},"description":"Benjamin Cane is a systems architect in the financial services industry. He writes about Linux systems administration on his blog and has recently published his first book, Red Hat Enterprise Linux Troubleshooting Guide.","url":"https:\/\/www.webcodegeeks.com\/author\/benjamin-cane\/"}]}},"_links":{"self":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts\/14856","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/users\/158"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/comments?post=14856"}],"version-history":[{"count":0,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts\/14856\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/media\/927"}],"wp:attachment":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/media?parent=14856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/categories?post=14856"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/tags?post=14856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}