News portal hosting in Nepal should be sized for concurrent readers, not monthly pageviews. A Nepali portal spends most of the month idle, then takes its entire month of traffic in twenty minutes when a story breaks. Full page caching, not a bigger plan, is what carries that spike.
Every Nepali portal owner I have worked with quotes me a monthly pageview figure. It is the wrong number. A portal doing two million views a month spread evenly is a small site. The same two million arriving with one earthquake, one election result or one political resignation is a different engineering problem entirely.
So this guide is organised around the spike, because everything else follows from it.
Where the spike comes from in Nepal?
Nepal had 14.8 million active social media user identities as of October 2025, half the population, against 16.6 million internet users, according to DataReportal’s Digital 2026 report. Practically everyone online is also on social media, and Facebook dominates that share.
That shapes traffic in a specific way. Readers do not arrive at your homepage and browse. A link is shared, it spreads through feeds and groups, and thousands of people land directly on one article within minutes. They read that article and they leave.
The consequences for hosting are concrete. Load concentrates on a single URL rather than spreading across the site. It arrives faster than any autoscaling reacts. And it is almost entirely mobile, from readers on mobile data rather than fixed broadband.
Add the predictable spikes to the unpredictable ones. Election results, budget day, examination results, festival periods and major sporting events are all on a calendar. You can prepare for those. Earthquakes and political crises give no warning at all, which is why the baseline configuration has to be right rather than something you switch on.
Size for concurrency, not for page-views
Here is the number that actually matters: how many people are on your site in the same second at peak.
Shared hosting plans advertise storage and bandwidth because those are easy to print. What constrains a news portal is none of those. It is the number of PHP processes your plan permits, the concurrent database connections available, and the memory each process can use.
A rough way to think about it. If a page takes 400 milliseconds of PHP time and your plan allows 10 concurrent PHP processes, you can serve roughly 25 uncached requests per second before requests begin queueing. For a portal at peak, 25 requests per second is nothing.
Which is exactly why the answer is not a bigger plan. It is making sure most requests never reach PHP at all.
Full page caching is the whole game
If you take one thing from this article, take this. A logged-out reader viewing a published article should receive a pre-built HTML page from cache, without WordPress or your database being involved.
Get that right and a modest server serves thousands of concurrent readers, because it is doing roughly what a static file server does. Get it wrong and no plan you can afford will hold.
The parts that need to be correct:
- Full page cache at the server level, not only a plugin. Server-level caching intercepts the request before PHP starts.
- Sensible purge rules. Publishing an article should clear the homepage, the relevant category pages and the article itself, not the entire cache. A full purge during a breaking story means every reader hits an empty cache at once, which is how sites fall over while technically having caching enabled.
- No cookie set on logged-out visitors that bypasses the cache. Analytics and consent scripts frequently do this by accident, and it silently disables caching for everyone. Check it by requesting an article with a fresh browser profile and reading the response headers.
- A CDN in front of the origin for static assets, and ideally for HTML too. This also puts content closer to readers outside Kathmandu and abroad.
I would rather see a portal on a modest plan with correct caching than a large plan with caching that quietly does nothing. The second setup is more common than the first.
Images are where Nepali portals waste the most
News is image-heavy by nature, and image handling is the most consistently neglected area I see.
The usual pattern is a photograph uploaded straight from a camera or a press release, two or three megabytes, displayed at 800 pixels wide. The reader on mobile data downloads the full file. Multiply that by a homepage of twenty thumbnails and the page weight becomes absurd.
What to fix, in order of return:
- Resize on upload. Nothing on the site needs to be wider than about 1600 pixels.
- Serve modern formats such as WebP or AVIF, with a fallback. The saving over JPEG is substantial at the same visual quality.
- Generate proper responsive sizes so a phone downloads a phone-sized image rather than a desktop one.
- Lazy load anything below the fold, but never the main article image, since delaying that hurts perceived speed and layout stability.
- Serve images from a CDN. Images are the bulk of your bandwidth, and offloading them takes real pressure off the origin.
One Nepal-specific point on fonts, which behave like images in this context. Devanagari webfonts are large. Loading several weights of a Nepali font blocks text rendering and costs more than most portals realise. Subset the font, limit yourself to two weights, and make sure text remains visible while the font loads rather than showing nothing.
Does the archive slow you down?
Less than owners fear, but in a specific way that matters.
Ten years of articles do not slow down a cached article page, because that page is being served from cache. Where depth hurts is anywhere a query has to scan the archive: search results, tag and category listings deep into their pagination, related-article widgets that query on every load, and the admin interface your editors use all day.
Three things worth doing as the archive grows. Limit post revisions, because a decade of drafts bloats the database more than the articles do. Make sure related-article and popular-post widgets are cached rather than querying live. And keep an eye on autoloaded options, which accumulate silently from plugins you removed years ago.
There is also a search engine angle. A very deep archive with thin tag pages spreads crawling thin. Noindex the tag and author archives that carry no unique value, and keep your sitemaps accurate so genuinely new articles are discovered quickly. For a news portal, being crawled fast matters more than for almost any other kind of site.
Third-party scripts undo everything else
You can do all of the above correctly and still ship a slow site, because most Nepali portals monetise with advertising and each ad network adds scripts you do not control.
Ad scripts, analytics, social embeds, comment systems and video players all execute on the reader’s phone. The server responded in 200 milliseconds and the page still takes eight seconds to become usable, because the browser is executing a dozen third-party scripts on a mid-range Android handset.
Being honest about the trade-off is more useful than pretending it away. Advertising pays for the newsroom. But load ad scripts asynchronously, reserve space for ad slots so content does not jump as they load, and audit quarterly, because ad tags accumulate and nobody removes the old ones.
Measure the site the way your readers experience it: on a mid-range Android phone on mobile data, not on office fibre.
When does a portal outgrow shared hosting?
Not at a pageview number. At one of these five signals.
- Your cache is configured correctly and the site still slows during ordinary peaks.
- Publishing is slow because the admin competes with readers for the same resources. Editors fighting the CMS during breaking news is a real operational cost.
- You need something shared hosting cannot give you, such as a specific PHP configuration, a persistent object cache, or a search service.
- Your host throttles you into slowness during exactly the events that matter most commercially.
- You are running video or large media directly from the origin server.
If none of those apply, a well-configured shared plan is genuinely fine, and I will say that even though the upgrade is the more profitable recommendation. Many Nepali portals move to a VPS to fix a problem that was actually a caching misconfiguration, and they take the misconfiguration with them.
When you do move, the honest trade-off is management. A VPS gives you resources and takes back the safety net. Someone now owns updates, security patches and backups. If nobody on your team owns that, managed hosting is worth more than raw specification.
Our news portal hosting plans are built around this profile, with local billing in rupees. If you are still planning the site itself rather than the infrastructure, our guide to what a Nepali business website needs covers the foundations.
The operational habits that matter more than the plan
Infrastructure is half of it. These habits are the other half.
Keep a static fallback. If your CMS fails during a major story, being able to publish a plain HTML page is better than being offline. Some portals keep a lightweight secondary page ready for exactly this.
Test your backups by restoring one, on a schedule. A backup nobody has restored is a hypothesis, not a backup.
Know your escalation path before you need it. During a spike is the wrong time to discover your host’s support hours or how to reach them.
And keep the licensing side in order. Online news portals in Nepal are registered with the Department of Information and Broadcasting and fall under Press Council Nepal oversight, alongside company registration and PAN. That is a separate exercise from hosting, but it belongs on the same launch checklist.
Frequently asked questions
Size by peak concurrent readers rather than monthly pageviews. With full page caching working correctly, a modest plan serves a large audience because most requests never reach PHP. Without it, no affordable plan will hold a breaking story.
Usually because logged-out readers are reaching PHP instead of a cached page. Requests exceed your plan’s PHP process or database connection limit, queue, and then time out. Check whether a cookie from an analytics or consent script is bypassing your cache.
Yes. Images are the bulk of a news site’s bandwidth, and serving them from a CDN removes that load from the origin. It also brings content closer to readers outside Kathmandu and to the diaspora audience most Nepali portals have.
Only if you have a reason. A VPS gives more resources and removes the safety net, so someone must own updates, patching and backups. Many portals upgrade to fix what was really a caching misconfiguration and carry the same problem to the new server.
Subset the Devanagari font to the characters you use, limit yourself to two weights, and configure the site so text stays visible while the font loads. Loading several full weights blocks rendering and costs more than most portals realise.
Yes. Online news portals register with the Department of Information and Broadcasting and come under Press Council Nepal oversight, in addition to company registration with the Office of Company Registrar and a PAN from the Inland Revenue Department.
