How we tested ConferenceAxis with Paul Bunyan

By The Web Design Ninja team · Prepared October 30, 2026

We wanted evidence before announcing the site.

Before launching the ConferenceAxis marketing website, our team used Paul Bunyan to look at the work behind the pages. We wanted to know whether the public pages returned successfully, whether the contact forms reached the mail handoff, and whether the diagnostic warnings pointed to work visitors were actually waiting for.

This was our own site and our own diagnostic tool. It is a first-hand development record, not an independent product review or a performance comparison with another profiler.

The test was deliberately narrow.

ConferenceAxis manages professional training conference workflows. This review covered its marketing site: Home, AgendaGuard, Continuing Education, the FLUG case study, Features, Pricing and Contact. It did not exercise attendee purchases, payment gateways, concurrent workshop bookings or continuing-education awards inside the conference application.

We used Paul Bunyan 1.1.4’s Profile one page control to load each public address as a logged-out visitor. Explicit profiles included query timing and watched every hook. Ordinary recording was configured separately: query tracing off, hook and error recording on, and email masking enabled.

Measurements were recorded on October 30, 2026. Each table row is one profiled server request, not a repeated benchmark, percentile or uninstrumented baseline. Profiling itself has overhead.

A warning needed context before it needed a fix.

Some early findings belonged to the work of preparing the site: a hook during a plugin update and the action that ran the cache test. These were not evidence that every conference visitor encountered the same delay.

A repeated query shape associated with UpdraftPlus onboarding appeared in an administrative request. Its recorded cost was about 13 ms in that earlier request. We kept it separate from the public-page profiles instead of treating the plugin’s presence as a reason to remove it.

Paul Bunyan also reported the absence of a persistent object cache. That is useful setup information, but it did not establish a public-page database bottleneck. In this small set of profiled requests, database time ranged from 5.8 to 20.4 ms. We did not turn on a cache service or change a vendor plugin merely to make the advisory disappear.

The form pause had a specific explanation.

After routing inquiries and launch-update requests to the owner-approved inbox, we submitted one test of each form. Both displayed their success messages. Paul Bunyan recorded 165.6 ms of mail work for the inquiry and 149.6 ms for the launch-update request.

The logger attributed the work to the child theme’s form handler and showed that the request included synchronous email sending. That explains a cost inside the request. It does not, by itself, mean that sending failed or that moving the work to a queue is automatically the right next change.

We left the mail path intact. The forms’ success branch followed WordPress reporting a successful send handoff, and the recipient still needed to confirm arrival in the inbox. No recipient addresses, visitor information or raw log exports are reproduced here.

We checked the missing-page path as well.

The team replaced the plain error layout with an editable ConferenceAxis error page. A separate logged-out profile confirmed that the missing address still returned HTTP 404, with a recorded server time of 146.9 ms. The page also carried a noindex directive.

That check mattered because an attractive error page is not enough: we wanted its HTTP behavior to remain correct. The wording stayed in an editable WordPress page; the shared theme handled the routing.

What we changed—and what we did not claim.

• We completed navigation, removed public placeholder content and checked interactive marketing controls.
• We verified the contact-form handoff and preserved the distinction between a send handoff and inbox delivery.
• We confirmed that the branded missing-page response remained a 404.
• We did not claim a percentage speed gain, a concurrency result, perfect Core Web Vitals or complete testing of the conference application.

The useful outcome was a record of what happened and where the time went. It helped us keep ordinary administrative work, server requests and remaining launch checks separate.

Related reading: WordPress debugging and speed guides · The team and product network behind ConferenceAxis

Questions about this guide

Does this study establish a speed improvement?

No. This review did not establish a before-and-after speed improvement. It recorded the site’s behavior and helped the team distinguish expected work, setup advice and issues worth investigating.

Are these Core Web Vitals results?

No. The table reports server request times from explicit logged-out profiles. It does not measure visitor network conditions, rendering, Largest Contentful Paint, Interaction to Next Paint or Cumulative Layout Shift.

Did the email tests prove delivery to the inbox?

No. The forms returned their success messages and Paul Bunyan recorded the outgoing mail work. Those checks establish the site-side handoff; inbox receipt still requires confirmation from the recipient.