Building a Fast Agency Site: My 7-Day Journey with the Noryx Theme
A local creative agency reached out to me last week. Their old WordPress site was built on a massive, heavy page builder. It took nearly six seconds to load on a standard mobile connection. They were losing leads, their Google Search Console was showing red warning flags for Core Web Vitals, and their editor was too complicated for their marketing team to make simple blog updates.
They wanted a clean, fast, and modern look. They had their eyes on the Noryx - Digital Agency & Creative WordPress Theme because they loved the dark, modern aesthetic and the portfolio layouts.
I agreed to rebuild their entire site in seven days. But as an architect who has worked with WordPress for over ten years, I told them we wouldn’t just install the theme, upload the demo content, and call it a day. We needed to audit the code, fix any layout shifts, optimize the database, and make sure it loaded in under 1.5 seconds.
This is my honest, day-by-day diary of how I rebuilt their site using Noryx, the real technical challenges I ran into, and the exact code snippets I used to fix them.
Day 1: Setup, Cleanup, and Code Inspection
Every good project starts on a local environment. I set up a fresh WordPress install on LocalWP using PHP 8.2 and Nginx. I always use a clean staging ground because importing demo content on a live site is a recipe for a messy database.
After installing a fresh copy of WordPress, I uploaded the Noryx theme zip file.
Before activating it, I wanted to see what was happening under the hood. I opened up the theme files in VS Code. Many modern agency themes are packed with custom post types, heavy bundled plugins, and duplicate asset calls.
My Code Inspection Notes: The Good: The template file structure is clean. It uses standard WordPress template hierarchy. The developers did not try to reinvent the wheel by hiding everything inside custom routing files. The Bad: Like most premium creative themes, it ships with a few heavy dependencies to make the front-end animations look cool. It relies on Elementor for page building, which means we have to be very careful with how we load our assets to keep the site fast. The Database: The demo importer is easy to use, but it imports a lot of extra images and menu items we don't need.
I ran the demo importer anyway to get a visual starting point. The client wanted the "Main Agency" layout. The import process took about three minutes.
Once it finished, I checked the database. The demo importer created over 120 media attachments, 12 custom templates, and loaded up the wp_options table with transient data.
Before going to sleep on Day 1, I ran my first WP-CLI cleanup routine. I logged into my local terminal and ran:
# Delete all unattached media imported by the demo that we don't need
wp media db cleanup
# Clear out transient options to keep the options table light
wp transient delete --allThis simple cleanup reduced the database size from 45MB down to 18MB right off the bat.
Day 2: Designing the Pages and Spotting the First Friction Point
On Day 2, I started replacing the demo content with the client’s real text, portfolio items, and team bios. This is where you usually find out how user-friendly a theme actually is for non-technical users.
The Noryx theme is built around Elementor, which is great for the client’s marketing team because they already know how to use it. The custom widgets included with the theme are well-designed. They make it easy to build those sleek, dark-mode grids that digital agencies love.
But in the afternoon, I hit my first real technical roadblock.
The client has a very specific style for their portfolio images. They use a strict 4:3 aspect ratio for all their case studies. However, the custom portfolio grid widget in Noryx was forcing images into its own hardcoded crop sizes. Because of this, the client’s beautifully shot project covers looked either squished or awkwardly cropped at the bottom.
I looked through the theme settings to see if there was a simple toggle to change the image size used in the portfolio loop. There wasn't one. The theme was calling a custom image size called noryx-portfolio-thumb directly in its widget rendering file, with no way to override it from the admin dashboard.
Many developers would just edit the theme’s core files to fix this. That is a terrible idea. The moment the theme gets an update, those core edits will be overwritten, and the client's site will break.
I needed a upgrade-safe way to fix this layout issue.
Day 3: Solving the Thumbnail Problem with a PHP Hook
On Day 3, I set out to solve the image cropping issue without editing the parent theme files. I created a custom child theme first. If you don't use a child theme, you shouldn't be building WordPress sites for clients.
Inside my child theme’s functions.php file, I wrote a PHP filter hook to intercept the image size definitions. I wanted to tell WordPress to ignore the theme's default crop settings for that specific image size and use our own custom 4:3 crop instead.
Here is the exact PHP filter I wrote and added to the child theme:
<?php
// Prevent direct access to the file
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
/**
* Override Noryx theme's custom thumbnail sizes to fit our client's 4:3 ratio.
*/
function my_custom_noryx_image_sizes( $sizes ) {
// We target the specific image size registered by the parent theme
$sizes['noryx-portfolio-thumb'] = array(
'width' => 800,
'height' => 600,
'crop' => true, // Force hard crop to keep the grid perfectly aligned
);
return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', 'my_custom_noryx_image_sizes' );
/**
* Register the new size officially so WordPress knows how to generate it
*/
function my_register_custom_portfolio_size() {
add_image_size( 'noryx-portfolio-thumb', 800, 600, true );
}
add_action( 'after_setup_theme', 'my_register_custom_portfolio_size', 11 );Regenerating the Images
Adding this code tells WordPress how to handle new uploads, but it does not fix the images we already imported or uploaded on Day 2.
To fix the existing images, I went back to my terminal and used WP-CLI to regenerate only the portfolio thumbnails. This is much faster than using a heavy, slow web-based plugin:
wp media regenerate --only-missing --yesI refreshed the portfolio page. The layout issue was gone. All the case study cards were aligned, and the images looked crisp without any weird stretching. The client was thrilled, and I knew the fix would survive any future theme updates.
Day 4: The Performance Audit and the Layout Shift Battle
By Day 4, the content was fully loaded. The site looked great. But looks don't matter to Google if the page takes forever to become interactive.
I ran my first lighthouse performance test on the homepage.
The results were okay, but not great: Performance Score: 68/100 (Mobile) First Contentful Paint (FCP): 2.4 seconds Cumulative Layout Shift (CLS): 0.28 (This is in the "poor" category)
A high CLS means elements on the page are jumping around while the page loads. It is annoying for users and hurts your search rankings.
I used Chrome DevTools to record the page load performance and find out what was causing the shifts.
I found two major issues:
- The Google Web Fonts: The theme was loading Google Fonts directly from Google's servers. This caused a brief flash of unstyled text (FOUT). The browser would first display a system serif font, and then jump when the Google Sans-style font finally loaded.
- The Hero Slider: The main header slider used a fade-in animation. Because the CSS for the slider was loaded in an external stylesheet that loaded late, the container had a height of 0px at start, and then expanded to 700px once the CSS file arrived.
We had some work to do.
Day 5: Fixing the Fonts and Writing Critical CSS
On Day 5, I tackled the performance bottlenecks we found during the audit.
Step 1: Hosting Fonts Locally
First, I disabled the theme's automatic Google Fonts loader. Loading fonts from third-party servers is bad for speed and bad for GDPR compliance in Europe.
I downloaded the font files (woff2 format) and uploaded them directly to the child theme folder. Then, I added @font-face rules to our CSS.
To ensure the browser knows these fonts are critical and should be loaded first, I added link preload tags to the header. I wrote a small hook in functions.php to inject these preloads:
/**
* Preload critical local fonts for better performance and zero font-flicker.
*/
function my_preload_local_fonts() {
$font_url_primary = get_stylesheet_directory_uri() . '/assets/fonts/custom-sans.woff2';
echo '<link rel="preload" href="' . esc_url( $font_url_primary ) . '" as="font" type="font/woff2" crossorigin>';
}
add_action( 'wp_head', 'my_preload_local_fonts', 1 );Step 2: Fixing the Hero Slider Layout Shift
To fix the height collapse of the hero slider before its main CSS loaded, I wrote a small block of critical inline CSS. This CSS is placed directly inside the <head> of the document so the browser parses it instantly before it even downloads the main theme stylesheets.
I added this to the child theme’s header template:
<style id="critical-path-css">
/* Reserve space for the hero banner to prevent Cumulative Layout Shift */
.noryx-hero-slider-container {
min-height: 80vh;
background-color: #121212; /* Match the dark theme background */
display: flex;
align-items: center;
justify-content: center;
}
@media (max-width: 768px) {
.noryx-hero-slider-container {
min-height: 60vh;
}
}
</style>This simple block of code tells the browser to immediately reserve an 80vh (80% of viewport height) dark box on the screen while the rest of the page layout engine works.
I ran another Lighthouse test. The CLS score dropped from 0.28 to 0.02. That is a massive win that pushed our Core Web Vitals into the green zone.
Day 6: Nginx Caching Rules and Database Fine-Tuning
By Day 6, the site was fast on my local server. But real production servers are different. They have to handle multiple real users at the same time.
I migrated the site to the client's staging server, which runs on an Nginx stack with fastcgi caching.
If you do not configure your caching rules properly, logged-in users might see cached pages, or your contact forms might stop working. I opened our Nginx configuration file and set up a solid caching structure.
Here is the Nginx server block configuration I used to handle caching, file compression, and security headers:
# Enable Gzip compression to shrink file sizes over the network
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml+rss text/javascript;
gzip_proxied any;
gzip_vary on;
# Cache control headers for static assets (Images, Fonts, CSS, JS)
location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff|woff2|svg)$ {
expires 365d;
add_header Cache-Control "public, no-transform";
access_log off;
log_not_found off;
}
# FastCGI Caching rules for dynamic pages
set $skip_cache 0;
# Don't cache POST requests
if ($request_method = POST) {
set $skip_cache 1;
}
# Don't cache URLs with query strings (like search results or UTM links)
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache if the user is logged into WordPress admin or has items in cart
if ($http_cookie ~* "comment_author|wordpress_[a_f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_index index.php;
}This configuration ensures that dynamic requests are cached at the server level, delivering pages in milliseconds, while instantly bypassing the cache for administrators editing the site or users sending emails via the contact page.
Day 7: Final Tests, Client Launch, and Honest Verdict
On Day 7, we did a final round of manual testing. We tested on iPhones, old Android devices, iPads, and different browsers (Chrome, Safari, Firefox).
Everything worked beautifully. The client's team learned how to add new portfolio items in under ten minutes, and the image resizing script handled all their uploads perfectly behind the scenes.
I ran a final Lighthouse speed test on the live production environment.
| Metric | Before Rebuild | After Rebuild (with Noryx + Fixes) |
|---|---|---|
| Mobile Speed Score | 34 / 100 | 91 / 100 |
| Desktop Speed Score | 62 / 100 | 97 / 100 |
| Fully Loaded Time | 6.2 seconds | 1.3 seconds |
| CLS (Layout Shift) | 0.38 | 0.02 |
The client was incredibly happy. We took a sluggish, outdated site and turned it into a highly optimized lead generation machine.
Honest Pros & Cons of the Noryx Theme
Now that I have lived with this theme inside a code editor for seven days, here is my objective review of the theme.
The Pros:
- Modern Aesthetic: The typography, spacing, and dark mode layouts are gorgeous out of the box. It looks like an elite agency site without needing custom UI design work from scratch.
- Elementor Compatibility: The theme includes custom Elementor widgets that are easy to use. The layout flexibility is fantastic.
- Clean Code Foundation: The underlying template files follow standard WordPress development practices. It is easy to write hooks and override layouts using a child theme.
The Cons & Friction Points:
- Rigid Image Sizes: The default theme forces specific thumbnail dimensions for grids, which can break custom asset ratios. You will need to write custom PHP filters (like the one I shared on Day 3) to adjust this.
- Animation Overhead: The heavy use of entrance animations can cause layout shifts (CLS) if you don't implement critical inline CSS or properly optimize your asset loading priority.
- Google Fonts Setup: The default implementation makes external API calls to Google's servers, which hurts load times. You must manually download the fonts and enqueue them locally if you want a high performance score.
My Final Takeaway
If you are a web designer or developer building a site for a creative agency, a marketing studio, or a portfolio-heavy client, the Noryx theme is a fantastic choice. The layout is striking and it catches the eye immediately.
However, do not expect to just click "Install" and get a perfect 99 score on Google PageSpeed. Like almost every premium WordPress theme on the market today, it requires a little bit of developer care. If you take the time to set up a child theme, fix the image cropping ratios, preload your local fonts, and apply server-level caching, you will end up with a blazing fast, gorgeous website that your client will love.
