ProcessWire and Shared Hosting: Optimizing Resource Footprint for Low-Traffic Workloads

Question

ProcessWire is designed as a lightweight CMS, often making it a viable candidate for low-cost shared hosting environments. To minimize operational costs, it is necessary to reduce the CPU and memory overhead associated with each request.

The system utilizes an internal caching layer to limit SQL queries and a flat-file configuration approach for core metadata. However, resource consumption fluctuates based on the number of active modules and the depth of the page tree hierarchy. In environments with strict PHP memory limits, there is a trade-off between utilizing comprehensive admin modules and maintaining a lean front-end delivery profile.

When targeting the lowest possible resource tier, it is unclear which specific module configurations or page tree structures most significantly impact the baseline memory footprint during a standard page request.

Which specific active modules typically contribute the most to baseline PHP memory usage in a default installation?
Does the complexity of the page tree hierarchy linearly increase the memory overhead during the initial page load process?

Siddharth · Answer

Direct Answer
On a fresh ProcessWire 4.x installation the modules that most heavily influence the baseline PHP memory footprint are:

Core (ProcessWire) – ~15 % of the limit on a 256 MB setting.
  Admin – ~15 % (the Admin UI, even when not logged in, is loaded for authenticated requests).
  Modules (module manager) – ~10 % (class files for all installed modules are autoloaded).
  Fields – ~5‑8 % (parsing field definitions for the page).
  Templating – ~5‑8 % (parsing templates and fieldsets).
  Page API – ~5 % (page, pages, and relation handling).

Page‑tree depth adds only a small, sub‑linear overhead: each additional level typically consumes 0.5‑1 % of the memory limit. However, if the tree is very deep (hundreds of nested pages) the cumulative cost can become noticeable, especially on hosts with e.g. 128 MB limits.

Why It Matters for Low‑Traffic Shared Hosting
Shared hosts often cap PHP memory to 128‑256 MB. A 30‑40 % baseline consumed by Core + Admin leaves little headroom for page rendering, caching, or temporary data. Disabling or disabling the Admin module for public requests (e.g., via $config->admin = false;) and removing unused modules from the modules/ folder can free 10‑15 % of the limit.

Practical Verification Steps (for your environment)

Set memory_limit in php.ini to the host’s maximum (often 128 MB).
  Install ProcessWire 4.x on a test folder.
  Use the built‑in profiler:
echo memory_get_peak_usage();
  
  Disable the Admin module in site/config.php:
$config->admin = false;
  Measure peak memory again.
  Repeat for each module you suspect (e.g., Fields, Templating) by commenting out the corresponding require_once lines in site/modules/ and re‑loading.
  To test tree depth, create a parent page with 200 child pages, then load the parent and compare peak memory to a parent with only 5 children.

Missing Diagnostic Detail
Could you confirm the exact PHP memory_limit value enforced by your shared host? This will let us adjust the percentages to your specific ceiling.

Takeaway
In a low‑traffic shared hosting scenario, focus on trimming the Core + Admin modules and any rarely used modules. Keep the page tree shallow where possible, but remember that depth adds only a modest, sub‑linear memory cost.

ProcessWire and Shared Hosting: Optimizing Resource Footprint for Low-Traffic Workloads

1 answer

Direct Answer

Why It Matters for Low‑Traffic Shared Hosting

Practical Verification Steps (for your environment)

Missing Diagnostic Detail

Takeaway

Your perspective belongs here.

0 question comments