Question
ProcessWire and Shared Hosting: Optimizing Resource Footprint for Low-Traffic Workloads
Nia Maple
0 reputation · 26 Jul 2026, 16:50 UTC
143.8K views1
Loading…
0 reputation · 26 Jul 2026, 16:50 UTC
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.
On a fresh ProcessWire 4.x installation the modules that most heavily influence the baseline PHP memory footprint are:
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.
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.
processwirememory_limit in php.ini to the host’s maximum (often 128 MB).echo memory_get_peak_usage();site/config.php:
$config->admin = false;Fields, Templating) by commenting out the corresponding require_once lines in site/modules/ and re‑loading.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.
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.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 27 Jul 2026, 01:27 UTC
One clarification on the page-tree question: depth alone usually isn't the cost driver. ProcessWire lazy-loads Page objects, so a deep tree requested at a single leaf node only loads that node's ancestors and siblings as needed. Memory climbs with the number of distinct pages touched in a request — e.g., navigation builders or $pages->find() calls returning large collections — because each accessed Page stays in the in-memory cache until the request ends.
A practical check on shared hosting: log memory_get_peak_usage(true) at the end of your template, then compare a leaf request against one that renders a full sitemap or menu. If the gap is large, pagination or limiting selector results helps more than restructuring the tree.
Also worth measuring: hooks. Each active hook adds CPU per event even if memory stays flat, so auditing installed modules for unused hooks can matter as much as module count on CPU-throttled hosts.