Website speed: what your host controls, and what it does not

Your host controls how quickly the server starts answering: the share of processor and memory your site gets, how up to date the server software is, and how far the server is from your visitors. Most of what a visitor waits for after that first answer is decided by the site itself: its images, scripts, fonts, theme and plugins. A good control panel puts the settings for both in your developer's hands, so choosing a good developer matters as much as choosing a good host. For sites that change rarely, a static site built with Hugo or Astro takes most of the server's work away altogether.

How speed is measured

Google's Core Web Vitals are the standard measures of how a page feels to a visitor. A page passes when 75% of visits meet the "good" mark.

A fourth measure, time to first byte (TTFB), is not a Core Web Vital but sits underneath all of them. It is the time from the visitor's request until the first byte of the page arrives. Google's web.dev suggests most sites aim for 0.8 seconds or less. TTFB is the first part of LCP, so a slow first answer delays everything after it.

What your host controls

The server decides most of the time to first byte. Google's own guide to improving it starts with hosting.

• Resources. How much processor and memory your site can use, and whether it shares PHP workers with other sites. On Noiz Premium, every tier has a dedicated PHP-FPM pool, so a neighbour's traffic cannot take your workers.
• Up-to-date server software. Newer versions of web servers, PHP and database software bring performance improvements as well as security fixes. Noiz runs nginx in front of Apache, PHP-FPM and MariaDB, and keeps the server and the Plesk panel patched.
• The PHP version. Each PHP release brings its own changes. On Premium you choose the PHP version for each site.
• Distance. Every request travels to the server and back, so the further the server is from your visitors, the longer each request takes.

What your site controls

Once the first byte arrives, the browser still has to fetch, run and draw everything the page asks for. That is the site's work, and it is where most slow pages lose their time.

• Images. Oversized images are the most common reason the largest element loads late. Serve images at the size they are shown, in modern formats such as WebP or AVIF, and never lazy-load the main image at the top of the page.
• JavaScript. Long-running scripts block the page from responding to clicks, which raises INP.
• Layout. Images without set dimensions, adverts and embeds of unknown size, and fonts that swap in late make the page jump.
• Fonts. Web fonts can delay text, and fonts loaded from other sites need extra connections.
• Third-party scripts. Chat widgets, trackers and embedded feeds each add requests you do not control.
• Theme and plugins. On WordPress, the number and quality of plugins and the theme decide much of the result.
• Redirects. Each extra redirect adds a round trip before the page even starts.

None of this changes when you move host. A heavy page on a better server is still a heavy page.

The control panel gives a good developer the controls

On Noiz shared hosting, the Plesk control panel gives you and your developer the settings that affect speed: the PHP version, how PHP is served, the web server configuration, scheduled tasks in place of page-load timers, and on Premium SSH access to your own account. Our help centre explains the choices:

• PHP handlers on Noiz hosting, and which to choose
• The recommended web server configuration on Noiz hosting
• Running WordPress on nginx without Apache
• Replacing wp-cron with a system cron
• How to speed up your WordPress site

Controls only help in the hands of someone who knows what they do. A developer who measures first, sizes images properly, chooses a lean theme and keeps plugins few will get more from any hosting plan than a bigger plan will. When you choose who builds your site, ask how they will measure its speed and what they will do about the results.

Build it static: Hugo and Astro

A static site is built once, on a computer or a build server, into plain HTML, CSS and images. When a visitor arrives, the server sends a file. There is no PHP to run and no database to query, so the server's part of the wait is as short as it gets, and there is far less on the live site to attack or keep updated.

• Hugo is an open-source static site generator (Apache 2.0 licence) that builds a complete site "in seconds, often less", by its own account.
• Astro is an open-source framework (MIT licence) that builds a fully static site by default. Its islands approach sends JavaScript only for the parts of a page that need it.

A built Hugo or Astro site runs on any Noiz plan. On Legacy you upload the files with the Plesk file manager. Premium adds SSH access to your own account.

A content editor for Astro: EmDash

Static sites have one drawback for many businesses: editing a page means editing files. EmDash, a free and open-source content management system (MIT licence) built on Astro and released as version 1.0 by Cloudflare in September 2026, gives an Astro site an editing screen. Its plugins run in a sandbox with only the permissions they declare.

EmDash runs as an application on a Node.js server, so it needs a Noiz Cloud server rather than a Legacy plan. If you would like an Astro site with EmDash, get in touch.

Measure before you change anything

Google's free PageSpeed Insights reports real visitor data from Chrome where your site has enough traffic, together with a lab test from Lighthouse. Run it on your busiest pages, note the three Core Web Vitals and the time to first byte, and test again after each change.

As a rule of thumb from the measures above:

• A high TTFB points at the server, the PHP version, slow database queries or too many redirects.
• A slow LCP with a good TTFB points at images, fonts or render-blocking files.
• A poor INP points at JavaScript.
• A poor CLS points at images, adverts or fonts without reserved space.

Ask us where the time goes

If your site feels slow, tell us what it does and how busy it gets. We will say whether a move to Premium would help, or whether the work belongs with your developer, and you can get in touch about a static rebuild with Astro where that fits better.

Sources

Checked 19 October 2026.

Measuring speed

• web.dev: Web Vitals
• web.dev: Largest Contentful Paint
• web.dev: Interaction to Next Paint
• web.dev: Cumulative Layout Shift
• web.dev: Time to First Byte
• web.dev: Optimize Time to First Byte
• web.dev: Optimize LCP
• web.dev: Optimize INP
• web.dev: Optimize CLS
• web.dev: Choose the right image format
• PageSpeed Insights: about
• Lighthouse overview
• WordPress: Optimization

Static sites and EmDash

• Hugo: introduction
• Hugo: licence
• Astro: configuration reference, output
• Astro: islands architecture
• Cloudflare blog: EmDash 1.0
• EmDash: deploy to Node.js

Noiz

• Shared hosting
• Cloud servers
• Noiz help centre: the guides linked in the article, at docs.noiz.ie

Note: while some of this content was produced with the help of AI, the final editing has been done by a real human being.