Engineering the Fastest B2B Wholesale Platform in the Philippines: Our 8 Server Optimization

What This Article Is About

Our Corporate Buyer and Bidder Verification Protocol from May 22 explained how we verify buyers, suppliers, and bidders using three email domain signals. MX records. Domain age. Business email detection. Verification is pass or fail. No exceptions. No manual review.

That article was about trust. It answered the question "Who are you?"

This article is about speed. It answers the question "How fast do you get served once we know who you are?"

The question of which B2B wholesale website in the Philippines loads the fastest comes up often. We cannot answer for other platforms. They do not publish their speed data. We publish ours.

Wholesale Dito Store already runs as a Progressive Web App or PWA. It was already faster than many wholesale websites. But we made eight configuration changes to make it even faster. No hardware upgrades. No server move. No expensive infrastructure overhaul. Just smarter server settings.

This article lists each change. It explains what each change does in plain language. It shows real test results from a command line tool called curl. It tells you how to run the same test yourself so you can verify our numbers.

The article also connects these speed changes to the three signal email domain verification system and explains why both are needed for the future of B2B wholesale, including bidding processes that are moving toward automation with AI agents.

Chapter 1:
Why Speed Matters

1.1 The Trust Then Speed Sequence

The May 22 white paper on corporate verification established a hard rule. Any corporate buyer, supplier, or bidder who wants to submit a Request For Quotation, apply for supplier accreditation, or access Invitation-to-Bid documents must pass email domain verification first.

That rule stops fraud. It stops fake inquiries. It stops middlemen who cancel orders after their own client backs out.

But verification only solves the identity problem. Once a buyer passes verification, they expect a fast experience. They have proven who they are. Now they want to see products, check bulk pricing, and submit orders without delay.

If the top wholesaler platform slows down after verification, the buyer gets frustrated. They remember the verification step as annoying. They associate the slowness with the whole experience. Some will leave and find another supplier even though their identity was already approved.

We built the verification system to filter out bad actors. We built the speed upgrades to keep good actors happy.

1.2 What Happens When A Website Is Slow

Data from multiple industry sources shows the same pattern. For every one second of delay, fewer people complete their transactions. For B2B transactions with higher order values and longer decision cycles, the impact is even larger because buyers have more chances to abandon the process.

A slow website does not just lose one sale. It trains buyers to expect slowness. They start using the platform only for research, then place orders by phone or email. That defeats the purpose of having an automated wholesale store.

We saw this pattern ourselves in the past. Verified buyers would submit an RFQ, wait for pages to load, then call our showroom to complete the order. They used the website as a catalog, not a transaction tool. That added labor costs on our side and frustration on their side.

1.3 How Search Engines Measure Speed

Google and other search engines measure website speed using specific metrics. Time to First Byte or TTFB is one of the most important. It measures how long the server takes to start sending data after a browser makes a request.

Google publishes recommended thresholds for these metrics. The search engine uses them to rank search results. Faster websites get higher positions for the same content.

The Google Search Central documentation states that page experience signals including Largest Contentful Paint or LCP, Interaction to Next Paint or INP, and Cumulative Layout Shift or CLS all factor into search rankings. A fast TTFB directly improves LCP because the browser receives the HTML payload sooner.

Source: Google Search Central Core Web Vitals

1.4 The Coming Shift To AI Agent Commerce

Industry analysts project a massive shift in how B2B buying happens. Gartner predicts that by 2028, 90 percent of B2B buying will be handled by AI agents. Forrester found that 74 percent of B2B organizations are already adopting or planning to adopt AI agents for procurement.

These AI agents act on behalf of corporate buyers. They authenticate using corporate email credentials. They submit RFQs across multiple suppliers at the same time. They compare pricing and terms algorithmically. Then they execute purchase orders without human approval at each step.

Here is what the analysts do not emphasize enough. AI agents will not wait. When an agent sends requests to multiple wholesale platforms simultaneously, it will process the first response first. It will compare that response against the others as they arrive. The slowest platform may not get considered at all even if its price is lower.

Our three signal email domain verification system is designed to work with these AI agents. The agents carry corporate email credentials. Our system checks MX records, domain age, and business email detection. That is the same verification process whether the request comes from a human or an agent.

But verification without speed is useless. An AI agent that waits three seconds for a quote will move on. The speed upgrades documented in this article ensure that when AI agents arrive, our platform responds fast enough to stay in consideration.

Source: Gartner Predicts 2025: AI Agents Transform B2B Buying

Source: Forrester The Rise Of AI Agents In B2B Commerce

Chapter 2:
The Eight Configuration Changes

Our server is not located in the Philippines. That is a fact we cannot change without major expense and operational restructuring. The physical distance adds a baseline latency to every single request. No software optimization can eliminate the time it takes for data to travel across the Pacific Ocean.

What we can control is what happens after the request arrives at our server. We made eight changes to reduce that processing time.

None of these changes required new hardware. None required moving to dedicated hosting or buying a VPS. All of them were configuration settings and code optimizations.

2.0 Overview: Before And After

2.1 OPcache On

OPcache is a PHP extension that stores compiled script code in shared memory. Without OPcache, the server reads and compiles the same PHP files on every single request. This includes core files that never change like product listing templates and checkout logic.

With OPcache enabled, the server compiles each file once and keeps the compiled version in memory. Subsequent requests skip the compilation step entirely.

This technology has been available in PHP for years. Many hosting configurations do not enable it by default because it consumes memory. We turned it on.

Status: On.

Source: PHP OPcache Documentation

2.2 JIT (Zend) On

JIT stands for Just In Time compilation. It takes the most frequently used PHP functions and compiles them directly into machine code. When those functions run, the CPU executes them directly without going through the Zend virtual machine that normally interprets PHP instructions.

JIT helps most with complex calculations. For a wholesale platform, these include bulk pricing tiers, volume discounts, shipping matrix calculations, and tax computations. These operations run on almost every page view. Speeding them up has a noticeable effect.

The PHP documentation explains that JIT compilation can improve CPU intensive operations by 30 to 50 percent.

Status: On.

Source: PHP JIT Configuration

2.3 PCRE JIT Now On

PCRE stands for Perl Compatible Regular Expressions. Every modern website uses regular expressions for pattern matching. When a buyer clicks a product link like /cleaning-products/floor-disinfectant, the server uses regular expressions to match the URL to the correct product page.

PCRE JIT compiles these pattern matching rules into machine code. Without JIT, the server interprets the patterns each time. With JIT, the compiled patterns run at hardware speed.

We turned this on. It was off before.

Status: Now On.

Source: PCRE2 JIT Documentation

2.4 APCu Enabled

APCu stands for Advanced PHP User Cache. It stores small pieces of local data in RAM. For a wholesale platform, these pieces include store settings, category structures, language translations, and navigation menus. These data pieces do not change often but the server needs them for every single page load.

Without APCu, the server reads these pieces from disk on every request. Disk reads are slow. With APCu, the server keeps them in RAM. RAM access is thousands of times faster than disk access.

APCu is different from OPcache. OPcache stores compiled code. APCu stores user data. Both are needed for optimal performance.

Status: Enabled.

Source: PHP APCu Documentation

2.5 Memcached Enabled

Memcached is a distributed memory caching system. It stores entire database query results in RAM. This is different from APCu, which stores small configuration pieces. Memcached stores large result sets like product listings and category pages.

Here is how it works in practice. The first time a buyer searches for floor disinfectant, the server runs a full database query. It finds matching products, checks inventory, applies pricing tiers, and builds the result page. This takes time. Memcached then stores that result in RAM.

The next time any buyer searches for floor disinfectant, the server skips the database query entirely. It pulls the pre built result from Memcached and serves it instantly. The database does not get touched.

For popular product categories and frequently searched items, Memcached eliminates almost all database work.

Status: Enabled.

Source: Memcached Project Documentation

2.6 AVIF Images Implemented With Mobile First Indexing In Mind

AVIF is a modern image format based on the AV1 video codec. It compresses images more efficiently than older formats like JPEG, PNG, and even WebP. Smaller file sizes mean faster downloads, especially on mobile connections.

We converted product images to AVIF format where the buyer's browser supports it. Browsers that do not support AVIF fall back to WebP or JPEG. The buyer does not notice the difference except that pages load faster.

This matters for search engines too. Google uses mobile first indexing. That means Googlebot crawls the mobile version of our site to decide rankings. Smaller image files mean Googlebot downloads product catalog pages faster. Faster crawling means more product pages get indexed. More indexed pages mean more chances to show up in search results when buyers look for cleaning supplies, paper products, or hotel amenities.

Google's own documentation confirms that using next gen image formats like AVIF improves Core Web Vitals scores, especially Largest Contentful Paint or LCP. Better LCP scores help with search rankings.

Status: Implemented.

Source: Google Developers Next Gen Image Formats

Source: AVIF Image Format Specification

2.7 New Relic Removed

New Relic is a monitoring tool that tracks application performance. It provides useful data for developers. But it also consumes CPU cycles and memory while running. The monitoring overhead adds milliseconds to every request.

We removed New Relic entirely. The tradeoff is that we have less detailed performance data. But the server has more resources available for processing actual buyer requests.

Status: Removed.

2.8 CSS Minification Via Custom Function

CSS files contain styling instructions for the website. Developers write these files with spaces, line breaks, and comments to make them readable. Browsers do not need any of that. They just need the instructions.

CSS minification removes all unnecessary characters. Spaces go away. Line breaks go away. Comments go away. What remains is a compact file that downloads faster.

Many platforms use third party plugins or build tools for minification. We wrote our own custom function that runs automatically when CSS files are generated. This gives us control over exactly what gets stripped and what stays.

Status: On. Custom function.

Chapter 3:
The Real Speed Test Results

We tested the website using curl, a standard command line tool for making HTTP requests. Curl provides precise timing data without any browser overhead. No cache. No extensions. No rendering time. Just raw server response.

The command we ran:

We ran this command ten times in a row from a terminal. No special conditions. No cherry picking. Just consecutive tests during normal operating hours.

Here are the results.

Averages across all ten tests:

• Connect time: 0.63 seconds
• TTFB: 1.54 seconds
• Total load time: 2.13 seconds
• Fastest total: 1.66 seconds
• Slowest total: 3.56 seconds

The slowest test shows normal internet variance. Sometimes network routes change. Sometimes there is congestion. Sometimes a packet gets dropped and retransmitted. One slow test out of ten is expected behavior for any website.

The average TTFB of 1.54 seconds is what matters. That is the time from when the server receives a request to when it starts sending back data. The faster this number, the better.

Source: curl Documentation Timing Variables

Chapter 4:
What These Numbers Mean For Buyers

Connect time is mostly out of our control. It depends on undersea cable routes, internet service providers, and the physical distance between the buyer and our server location. Our average connect time of 0.63 seconds is simply the cost of doing business across the Pacific Ocean.

TTFB is where our server optimizations matter. The average of 1.54 seconds means that once the request arrives, our server processes it and starts responding in about one and a half seconds. That is the result of the eight configuration changes we made.

For a buyer in Cavite, Laguna, Batangas, or Metro Manila, the practical experience is a total page load time between 1.6 and 2.2 seconds most of the time. Occasionally a test runs slower due to network conditions, but the average is consistent.

The most important number is not the average. It is the fastest test at 1.66 seconds. That shows what the server is capable of when network conditions are good. Our job is to make that fast experience happen more consistently.

The World Wide Web Consortium or W3C maintains the Navigation Timing Level 2 specification, which sets the standard for measuring these performance metrics across all browsers.

Source: W3C Navigation Timing Level 2

Chapter 5:
How This Connects To The Corporate Buyer And Bidder Verification Protocol

The Corporate Buyer and Bidder Verification Protocol describes a three signal verification system. Check MX records. Check domain age. Check that the email is from a business domain, not Gmail or Yahoo. Pass all three and the buyer gets access to RFQ submission, supplier applications, and Invitation-to-Bid documents.

That system is now in development with target rollout in Q3 2026. It creates a verified pool of buyers, suppliers, and bidders. These are the only entities that can transact on the platform.

But a verified pool is useless if the platform is slow. Verified buyers expect speed. They have already gone through the friction of verification. If they then encounter slow page loads, they will associate the entire platform with frustration.

The speed upgrades documented in this article ensure that once a buyer passes verification, the transaction experience is as fast as we can make it given the physical distance constraints. The buyer proves who they are. Then they get fast service.

This two part approach of verification plus speed is designed specifically for the coming wave of AI agent procurement. The AI agent will authenticate using corporate email credentials. Our three signal email domain verification system will process that authentication instantly. Then our fast server response will ensure the agent gets a quote quickly enough to be competitive.

Chapter 6:
Why This Matters For Bidding And Procurement

Wholesale Dito Store serves corporate buyers across multiple industries. Hotels need linens and amenities. Restaurants need cleaning supplies and paper products. Hospitals need sanitation chemicals and hygiene essentials. Offices need breakroom supplies and janitorial equipment.

Many of these buyers participate in formal bidding processes. A hospital might issue an Invitation-to-Bid for a year supply of floor disinfectants. A hotel group might request bids for bulk towel and sheet purchases across multiple properties.

These bidding processes have strict timelines. Bidders must submit proposals by specific deadlines. Any delay in accessing bid documents, submitting questions, or uploading responses can disqualify a bidder entirely.

A slow wholesale platform creates real risk in these situations. A bidder who cannot load the bid documents page because the server is slow might miss a critical specification. A supplier who cannot submit their bid because the RFQ form times out might lose a contract.

The speed upgrades we made directly benefit bidders. Faster page loads mean faster access to Invitation-to-Bid documents. Faster form submissions mean fewer timeouts and failed uploads. Faster overall experience means bidders can focus on their proposal content instead of fighting the platform.

We are building infrastructure to support formal bidding processes. That includes the verification system from May 22 to ensure only legitimate bidders participate. It includes the speed upgrades from this article to ensure those legitimate bidders can work efficiently.

Chapter 7:
How You Can Test The Speed Yourself

You do not need to trust our numbers. You can run the same test from your own computer.

If you have a Mac or Linux computer, open the Terminal application. If you have Windows, you can install curl or use Windows Subsystem for Linux.

Type this command and press enter:

The terminal will show three numbers. Connect time. TTFB. Total time.

Your numbers will vary from ours. Your internet connection is different. Your location in the Philippines is different. The time of day is different. Network congestion is different. That is normal.

But you will see real numbers. Not marketing claims. Not screenshots from a testing tool that someone else controlled. You will have run the test yourself.

That is the level of transparency we commit to. We do not ask you to believe us. We show you how to verify our claims with your own hands.

Chapter 8:
The Bottom Line

We made eight configuration changes to speed up Wholesale Dito Store.

• OPcache on.
• JIT on.
• PCRE JIT now on.
• APCu enabled.
• Memcached enabled.
• AVIF images implemented.
• New Relic removed.
• CSS minification via custom function.

We tested the results using curl from a terminal. Ten consecutive tests. Average TTFB of 1.54 seconds. Average total load time of 2.13 seconds.

These numbers are not the fastest possible. The physical distance between our server and the Philippines adds unavoidable latency. But these numbers are real. They are verifiable. You can run the same test yourself.

The speed upgrades connect directly to our Corporate Buyer and Bidder Verification Protocol. That system verifies corporate buyers, suppliers, and bidders using email domain signals. It ensures that only legitimate entities can submit RFQs, apply for accreditation, or access bidding documents.

Verification proves who you are. Speed proves how fast we serve you once we know who you are. Both are necessary for the coming shift to AI agent driven procurement.

Industry analysts project that within two years, most B2B buying will be handled by AI agents. Those agents will authenticate using corporate email credentials. Our verification system handles that. Those agents will compare response times across multiple platforms. Our speed upgrades ensure we respond fast enough.

The same infrastructure that serves human buyers today will serve AI agents tomorrow. Faster page loads help both. Faster TTFB helps both. Faster database queries help both.

We built the verification system for trust. We built the speed upgrades for performance. Together they prepare Wholesale Dito Store for the future of B2B wholesale, including bidding processes that demand both security and speed.

Run the curl test yourself. See the numbers. Then submit an RFQ and experience the difference.

References and Sources

• Google Search Central. Core Web Vitals and Page Experience Signals.
• Gartner. Predicts 2025: AI Agents Transform B2B Buying.
• Forrester. The Rise Of AI Agents In B2B Commerce.
• PHP Documentation. OPcache Configuration.
• PHP Documentation. JIT Configuration.
• PCRE Library Documentation. PCRE2 JIT Optimization.
• PHP Documentation. APCu User Cache.
• Memcached Project. About Memcached.
• Google Developers. Next Gen Image Formats.
• AVIF Image Format Specification.
• curl Documentation. Timing Variables.
• World Wide Web Consortium (W3C). Navigation Timing Level 2 Specification.
• Internet Engineering Task Force (IETF). RFC 5321: Simple Mail Transfer Protocol.