DEV Community: Mecanik Dev

Securing Linux Servers with CSF: The Ultimate Guide for 2023

Mecanik1337 — Wed, 07 Oct 2026 18:00:00 +0000

Linux servers have gained tremendous popularity among businesses and individuals due to their flexibility, cost-effectiveness, and powerful performance. However, ensuring the security of these servers is of paramount importance.

In this article, we'll explore how to secure Linux servers using CSF (ConfigServer Security & Firewall) or similar software, and provide you with links and examples to fortify your server.

What is CSF?

CSF is a powerful, stateful firewall that is specifically designed for Linux servers. It provides an easy-to-use interface and comprehensive security features, making it a popular choice among system administrators.

CSF is not only a firewall but also an intrusion detection system, actively monitoring and blocking malicious activity.

You can learn more about CSF and its features on their official website: ConfigServer Security & Firewall.

Why Choose CSF?

There are several reasons to choose CSF over other firewall solutions for your Linux server:

Easy installation and setup
Regular updates and active community support
Compatibility with most Linux distributions and control panels
Comprehensive security features, including intrusion detection and login failure tracking
Customizable configuration options

How to Install and Configure CSF

Before installing CSF, it's essential to uninstall or disable any other firewalls on your server. Follow these steps to install and configure CSF:

Log into your server as the root user via SSH.
Download the latest version of CSF using the command:

wget https://download.configserver.com/csf.tgz

Extract the downloaded archive:

tar -xzf csf.tgz

Navigate to the extracted directory and run the installer script:

cd csf
sh install.sh

Open the configuration file at /etc/csf/csf.conf with your favorite text editor (e.g., nano or vim). Customize the settings to suit your security requirements.
After configuring CSF, test your server's compatibility by running:

perl /usr/local/csf/bin/csftest.pl

If the test is successful, enable CSF by changing the TESTING setting in the configuration file to 0.
Restart CSF to apply the changes:

csf -r

For more detailed instructions and configuration options, refer to the official CSF documentation.

Optimal CSF Configuration for Enhanced Security

Here are some recommended settings for an optimal CSF configuration to enhance your Linux server's security.

Keep in mind that these settings might not be suitable for every server environment, so it's important to tailor them according to your specific needs. Always test any changes before implementing them on a production server.

Restrict Incoming and Outgoing Connections

Limit incoming and outgoing connections to only the necessary ports by specifying them in the TCP_IN, TCP_OUT, UDP_IN, and UDP_OUT sections. For example:

TCP_IN = "22,80,443"
TCP_OUT = "22,80,443,53"
UDP_IN = "53"
UDP_OUT = "53"

Enable Login Failure Detection

Ensure that CSF tracks login failures by enabling the LF_* options in the configuration file:

LF_TRIGGER = "5"
LF_SSHD = "5"
LF_FTPD = "10"
LF_SMTPAUTH = "5"
LF_POP3D = "10"
LF_IMAPD = "10"

This example sets a trigger for a temporary block after 5 failed login attempts within the specified time period for SSH, FTP, SMTP, POP3, and IMAP.

Enable Process Tracking

Monitor server processes for suspicious activity by enabling process tracking:

PT_LIMIT = "60"
PT_USERMEM = "200"
PT_USERTIME = "1800"
PT_USERKILL = "1"

This example sets a 60-second interval for process tracking, with a memory usage limit of 200 MB, a maximum process time of 1800 seconds, and the ability to kill processes that exceed these limits.

Remember to restart CSF after making any changes to the configuration file:

csf -r

Using Profiles in CSF for Enhanced Security

Profiles in CSF are predefined sets of configuration options tailored to specific use cases or security levels. They allow you to quickly switch between different configurations without manually adjusting individual settings.

This can be especially useful when you want to enforce stricter security measures or relax the rules temporarily. In this section, we'll explain what profiles are, how to use them, and some considerations when implementing them.

What are CSF Profiles?

CSF profiles are essentially configuration files that store specific settings for different scenarios. These profiles can be applied with a single command, making it easy to switch between various security configurations.

CSF comes with several default profiles, each designed for a particular purpose, such as a web server or a mail server.

How to Use CSF Profiles

First, navigate to the CSF profile directory:

cd /usr/local/csf/profiles

List available profiles:

ls

You should see a list of default profiles, such as webserver.conf, mailserver.conf, and default.conf.

To apply a profile, use the following command:

csf --profile <profile_name>

For example, to apply the webserver.conf profile, use:

csf --profile webserver

If you want to create your custom profile, copy the existing configuration file to the profiles directory:

cp /etc/csf/csf.conf /usr/local/csf/profiles/my_custom_profile.conf

Then, edit the my_custom_profile.conf file using your preferred text editor, and adjust the settings to suit your needs. Once you've made the changes, you can apply the custom profile using the same command mentioned earlier.

Considerations When Using CSF Profiles

Backup your current configuration before applying a new profile. This ensures that you can easily revert to the previous settings if needed.
Test the new profile in a non-production environment before applying it to a live server. This helps identify any potential issues or conflicts that could arise.
When creating custom profiles, ensure that you follow best practices for securing Linux servers, and consider your specific use case and environment.
Regularly review and update your profiles to stay up-to-date with the latest security recommendations and best practices.
Keep in mind that applying a new profile will overwrite the current settings. Make sure to double-check the contents of the profile before applying it, especially if you're using a custom profile or have made changes to the default profiles.

By understanding and utilizing CSF profiles, you can efficiently manage and switch between different security configurations for your Linux server. This not only saves time but also ensures that your server stays protected under various circumstances.

Setting Up the CSF User Interface

CSF provides a web-based user interface (UI) for managing and configuring the firewall. This graphical interface is particularly useful for those who are not comfortable working with command-line tools or prefer a visual way of managing settings.

In this section, we'll walk you through setting up the CSF UI and discuss some considerations for using it.

How to Set Up the CSF UI

The CSF UI is available by default for popular control panels such as cPanel, DirectAdmin, and Webmin. If you are using one of these control panels, the CSF UI should already be integrated into your panel.

For other control panels or a server without a control panel, you can set up the CSF UI using the following steps:

Ensure that you have the required dependencies installed on your server:

Perl
The LWP (libwww-perl) module
The GD (libgd) module
The GD::Graph module

You can install these dependencies using your package manager. For example, on Ubuntu:

sudo apt-get install perl libwww-perl libgd-dev libgd-perl libgd-graph-perl

Open the CSF configuration file at /etc/csf/csf.conf with your favorite text editor (e.g., nano or vim).
Locate the following settings and modify them as follows:

UI = "1"
UI_PORT = "<your_desired_port>"
UI_USER = "<your_username>"
UI_PASS = "<your_password>"

Replace <your_desired_port> with an unused port number (e.g., 8080), <your_username> with a username of your choice, and <your_password> with a strong, unique password.

Save and close the configuration file.
Restart CSF to apply the changes:

csf -r

Access the CSF UI by navigating to http://your_server_ip:<your_desired_port> in your web browser, and log in with the username and password you specified in the configuration file.

How to Set Up HTTPS for the CSF UI

It's essential to secure the CSF UI with HTTPS to protect your login credentials and data transmission. Using HTTPS is highly recommended, especially when accessing the UI over the internet.

In this section, I'll show you how to set up HTTPS for the CSF UI using Let's Encrypt, ACME, or Certbot, and where to place the generated certificates so CSF can read them.

HTTPS with Certbot

Ensure that you have Certbot installed on your server. You can follow the instructions for your specific distribution on the Certbot website.
Generate a certificate for your domain using Certbot:

sudo certbot certonly --standalone -d example.com

Replace example.com with your domain. Make sure the domain points to your server's IP address.

After generating the certificate, you will find the certificate files in the /etc/letsencrypt/live/example.com/ directory. The files you need are fullchain.pem (the certificate) and privkey.pem (the private key).
Copy the certificate files to a location where CSF can read them:

sudo cp /etc/letsencrypt/live/example.com/fullchain.pem /etc/csf/ui/ssl/cert.pem
sudo cp /etc/letsencrypt/live/example.com/privkey.pem /etc/csf/ui/ssl/key.pem

Open the CSF configuration file at /etc/csf/csf.conf with your favorite text editor (e.g., nano or vim).
Modify the following settings:

UI_SSL = "1"
UI_CERT = "/etc/csf/ui/ssl/cert.pem"
UI_KEY = "/etc/csf/ui/ssl/key.pem"

Save and close the configuration file.
Restart CSF to apply the changes:

csf -r

Now, you can access the CSF UI securely over HTTPS by navigating to https://example.com:<your_desired_port> in your web browser.

Remember to renew the Let's Encrypt certificate every 90 days, as they have a short validity period. You can automate this process using a cron job.

Keep in mind that HTTPS is necessary and highly recommended for securing the CSF UI. By following these steps, you can ensure that your login credentials and data transmission remain safe from potential threats.

Considerations When Using the CSF UI

Choose a strong, unique password for the CSF UI to prevent unauthorized access. Make sure to update the password regularly and avoid using the same password for other services.
Restrict access to the CSF UI by allowing only specific IP addresses to connect to the UI. You can do this by modifying the UI_ALLOW setting in the CSF configuration file:

UI_ALLOW = "192.168.1.1,192.168.1.2"

Replace the example IP addresses with the ones you want to allow access to the CSF UI.

Ensure that the chosen port for the CSF UI is not already in use by other services. Additionally, it's recommended to choose a non-standard port to reduce the chances of automated attacks.
Regularly update the CSF UI and its dependencies to protect against known vulnerabilities and security issues.
Monitor access logs to identify any suspicious activity or unauthorized login attempts. CSF logs can be found at /var/log/lfd.log.

By setting up and using the CSF UI, you can efficiently manage and configure your firewall settings through an easy-to-use graphical interface.

Make sure to follow best practices and consider the points mentioned above to maintain a secure and reliable environment.

CSF Protection Against DDoS Attacks

CSF can help protect your server against Distributed Denial of Service (DDoS) attacks by implementing various configurations and security measures.

In this section, I'll cover how CSF can defend against DDoS attacks and provide some example configurations and recommendations.

SYN Flood Protection

SYN flood attacks are a type of DDoS attack where an attacker sends a large number of SYN packets to a server, causing it to exhaust its resources while trying to establish connections.

To enable SYN flood protection in CSF, adjust the following settings in the /etc/csf/csf.conf file:

SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"

These settings will enable SYN flood protection and configure the rate and burst limits for incoming connections.

Connection Limit Protection

By limiting the number of simultaneous connections to your server, you can mitigate DDoS attacks targeting specific services.

To enable connection limit protection, configure the CONNLIMIT setting:

CONNLIMIT = "22;5,80;50,443;50"

This example limits the number of connections to 5 for SSH (22), 50 for HTTP (80), and 50 for HTTPS (443).

Port Flood Protection

Port flood protection helps defend against DDoS attacks that target specific ports on your server.

To enable port flood protection, configure the PORTFLOOD setting:

PORTFLOOD = "22;tcp;5;300,80;tcp;30;5,443;tcp;30;5"

This example limits the rate of new connections for SSH (22) to 5 per 300 seconds, and for HTTP (80) and HTTPS (443) to 30 per 5 seconds.

Blocklists

CSF can integrate with various IP blocklists to prevent known malicious IP addresses from accessing your server.

To enable blocklist integration, configure the BLOCKLIST_* settings in the CSF configuration file:

BLOCKLIST_DE = "1"
BLOCKLIST_6DE = "1"
BLOCKLIST_DE_URL = "https://lists.blocklist.de/lists/all.txt"
BLOCKLIST_6DE_URL = "https://lists.blocklist.de/lists/ipv6/all.txt"

This example enables integration with the blocklist.de blocklists for both IPv4 and IPv6 addresses.

Country-Level Blocking

CSF allows you to block access from specific countries using the CC_DENY and CC_ALLOW_FILTER settings. While this method may not be suitable for all situations, it can be useful in cases where you want to restrict access from countries known for launching DDoS attacks.

CC_DENY = "CN,IR,RU"
CC_ALLOW_FILTER = "US,CA,GB"

This example blocks access from China (CN), Iran (IR), and Russia (RU) and only allows incoming connections from the United States (US), Canada (CA), and the United Kingdom (GB).

Remember to restart CSF after making any changes to the configuration file:

csf -r

By implementing these configurations and recommendations, you can significantly enhance your server's protection against DDoS attacks.

Keep in mind that no security measure is foolproof, so it's crucial to regularly monitor your server for potential threats and adapt your CSF settings accordingly.

Alternative Security Solutions

While CSF is an excellent choice for Linux server security, you might want to consider alternative solutions that offer similar features:

UFW (Uncomplicated Firewall): A user-friendly firewall for Ubuntu-based systems.
Firewalld: A firewall management tool for Linux distributions that use systemd.
IPTables: A powerful command-line tool for packet filtering and network address translation on Linux.

Conclusion

Securing your Linux server is essential to protect your data and maintain your server's integrity. CSF provides a powerful and user-friendly solution to achieve this goal.

By following the steps outlined in this article, you can easily install and configure CSF on your Linux server. Don't forget to explore alternative security solutions like UFW, Firewalld, and IPTables if you're looking for additional options.

I hope you found this article helpful and informative in securing your Linux server with CSF. If you enjoyed this article and found it valuable, please feel free to share it with others who might benefit from it. I also encourage you to leave a comment with your thoughts or questions, and I'll be more than happy to help. 😊

Stay vigilant and keep your servers secure in 2023 and beyond!

Ecommerce Website Development: Shopify vs Custom

Mecanik1337 — Wed, 07 Oct 2026 06:00:00 +0000

Ecommerce website development is one of the highest-stakes decisions an online retailer makes, because the platform you choose shapes your costs, your flexibility, and your ceiling for growth. In 2026 the core question for most UK businesses comes down to this: a hosted platform like Shopify, or a custom build. Both can run a successful store. They suit very different situations. This guide compares them honestly on cost, control, performance, scalability, and SEO, then gives a clear recommendation for each type of retailer.

TL;DR

Shopify is the right default for most small and mid-sized UK retailers: fast to launch, low maintenance, and reliable out of the box
Custom ecommerce development wins when you have unusual requirements, complex integrations, or scale that platform fees and limits start to constrain
WooCommerce sits in between: open-source flexibility on WordPress, but with more maintenance responsibility on you
The biggest hidden costs of hosted platforms are transaction fees and app subscriptions, which add up as you grow
Choose the platform around your actual requirements and growth plan, not around what is trendy

The Ecommerce Platform Landscape in 2026

Ecommerce website development falls into three broad approaches. Hosted platforms like Shopify handle the infrastructure, security, and updates for you in exchange for a monthly fee and, often, transaction charges. Open-source platforms like WooCommerce give you the software for free but make you responsible for hosting and maintenance. Custom development builds the store, or parts of it, specifically for your business.

None of these is universally best. A store selling 20 products has very different needs from one selling 20,000 with complex pricing rules and warehouse integrations. The right choice is the one that matches your requirements today and gives you room to grow without a painful rebuild.

Shopify: Strengths and Limits

Shopify dominates UK ecommerce for good reasons. It is fast to set up, handles hosting and security for you, processes payments reliably, and has a vast ecosystem of themes and apps. For a retailer who wants to start selling quickly without managing technical infrastructure, it is hard to beat.

The trade-offs appear as you scale. Shopify charges monthly subscription fees, and unless you use Shopify Payments, additional transaction fees on every sale. The app ecosystem that makes Shopify flexible also means recurring subscription costs, since many features you need are paid third-party apps. Deep customisation is constrained by what the platform allows; you work within Shopify's structure rather than around it.

For most small and mid-sized retailers, those limits never bite. For high-volume stores or businesses with unusual workflows, they eventually do.

Custom Ecommerce Development: Strengths and Limits

A custom ecommerce build means the store is developed specifically for your business, typically on a framework rather than a hosted platform. The advantage is total control. There are no platform limits on functionality, no per-transaction platform fees, and the design and checkout flow can be built exactly around how you sell.

This control comes at a price. Custom development costs more upfront and takes longer to launch. You are responsible for hosting, security, and maintenance, which our website security audit guide covers in depth. And you need a capable development partner, because a custom store is only as good as the team behind it.

Custom development pays off when your requirements genuinely exceed what platforms offer, or when your sales volume makes platform and transaction fees more expensive than running your own infrastructure.

Shopify vs WooCommerce vs Custom: Side by Side

Criterion	Shopify	WooCommerce	Custom build
Setup speed	Fast	Moderate	Slow
Upfront cost	Low	Low to moderate	High
Monthly cost	Subscription + fees	Hosting + plugins	Hosting only
Customisation	Limited to platform	High	Unlimited
Maintenance burden	Minimal (Shopify handles it)	On you	On you
Scalability	Good, within limits	Good with effort	Excellent
Transaction fees	Often yes	No (just payment processor)	No (just payment processor)
Best for	Most SMEs	WordPress-based retailers	Complex or high-volume stores

Performance and SEO for Ecommerce

For an online store, performance is revenue. Slow pages lose sales, and Google's Core Web Vitals make speed a ranking factor. This is one area where the platform choice has real consequences.

Shopify delivers solid performance out of the box, though heavy use of third-party apps can slow a store down, since each app often adds scripts. WooCommerce performance depends heavily on your hosting and how the site is built; a poorly optimised WooCommerce store can be slow, while a well-built one is fast. Custom builds can achieve the best performance because nothing is included that you do not need, but only if performance is a deliberate priority during development.

SEO follows similar logic. All three approaches can rank well, but custom and well-built WooCommerce stores give you the most control over technical SEO, URL structure, and page speed. Whichever route you take, image optimisation matters enormously for stores with large catalogues, which is why we cover techniques like Cloudflare image resizing for WordPress for WooCommerce-based shops.

Security and Payments

Taking payments online means taking security seriously. Hosted platforms like Shopify handle PCI compliance and security updates for you, which removes a significant burden and risk. With WooCommerce or a custom build, that responsibility shifts to you and your development partner: keeping software patched, hardening the server, and ensuring the payment flow is secure.

This is a genuine factor in the decision. If you do not have the resources or appetite to manage security properly, a hosted platform's built-in protection is worth a great deal. If you do, a custom or self-hosted store gives you more control over the entire payment experience.

When to Choose Shopify

Choose Shopify if you want to launch quickly, sell a manageable catalogue, and avoid managing technical infrastructure. It suits most small and mid-sized UK retailers, especially those without an in-house technical team. The monthly and transaction fees are a fair trade for not having to run, secure, and maintain the platform yourself. If your store is your business but technology is not, Shopify is usually the pragmatic answer.

When to Choose a Custom Build

Choose custom ecommerce development when your requirements outgrow what platforms allow. That includes complex pricing or subscription models, deep integrations with ERP or warehouse systems, very large catalogues, unusual checkout flows, or sales volumes high enough that platform and transaction fees become a meaningful cost. At that point, the upfront investment in a custom store is justified by the control, performance, and savings it delivers. Our guide on WordPress versus custom web development explores this build-versus-buy decision more broadly.

The Honest Recommendation for 2026

Most UK retailers should start with Shopify or a well-built WooCommerce store, and only move to custom development when they have concrete evidence that platform limits are holding the business back. Starting custom because it sounds more serious usually means paying for flexibility you do not yet need and taking on maintenance you are not ready for.

The reverse mistake also happens: staying on a hosted platform long after transaction fees, app subscriptions, and customisation limits have started costing real money. The right move is to match the platform to where the business actually is, and to revisit the decision as it grows.

Key Takeaways

Shopify is the pragmatic default for most UK retailers: fast, reliable, and low-maintenance, with fees that grow as you scale
Custom ecommerce development offers unlimited control and no platform fees, at higher upfront cost and maintenance responsibility
WooCommerce sits between the two: flexible and open-source, but you manage hosting and security
Performance and SEO are achievable on all three, but custom and well-built stores give the most control
Hosted platforms handle PCI compliance and security for you; self-hosted stores shift that responsibility to you
Match the platform to your real requirements and growth plan, and revisit the decision as the business scales

Frequently Asked Questions

Is Shopify or a custom website better for ecommerce?
For most small and mid-sized UK retailers, Shopify is better because it is fast to launch and handles hosting, security, and maintenance. A custom build becomes better when you have complex requirements, deep integrations, or sales volumes where platform and transaction fees outweigh the cost of running your own store.

How much does ecommerce website development cost in the UK?
A Shopify store with light customisation can cost a few thousand pounds plus monthly fees, while a custom ecommerce build typically ranges from £8,000 to £40,000 or more depending on complexity. Catalogue size, integrations, and design effort are the main cost drivers.

Is WooCommerce better than Shopify?
Neither is universally better. WooCommerce offers more flexibility and no platform transaction fees, but you manage hosting, security, and updates. Shopify is easier and lower-maintenance but charges subscription and often transaction fees. The right choice depends on your technical resources and customisation needs.

Does the ecommerce platform affect SEO?
Yes. All major platforms can rank well, but they differ in how much control you have over technical SEO, URL structure, and page speed. Custom and well-built WooCommerce stores generally offer the most SEO control, while Shopify provides a solid, lower-effort foundation.

Do I need a developer to build an ecommerce website?
Not always for a basic Shopify store, which you can set up yourself. But a developer adds significant value for custom design, performance optimisation, complex functionality, and any custom or WooCommerce build. The more your store needs to do, the more a capable development partner matters.

Are transaction fees a big deal on Shopify?
They can be as you scale. Shopify charges subscription fees, and additional transaction fees apply unless you use Shopify Payments. For a low-volume store these are minor, but for a high-volume retailer they add up, which is one reason large stores sometimes move to custom platforms.

Learn Programming Fundamentals: Choosing the Right Language

Mecanik1337 — Tue, 06 Oct 2026 18:00:00 +0000

Embarking on a journey into the world of programming can be both exciting and overwhelming. With countless programming languages to choose from, it's essential to pick the right one that aligns with your goals and aspirations.

In this article, we will explore the factors to consider when choosing your first programming language and provide examples of code in popular languages to help illustrate the differences between them.

Factors to Consider When Choosing a Programming Language

Career Goals: If you plan to pursue a career in software development, it's essential to research which programming languages are in demand for the industries you're interested in.
Learning Curve: Some languages have a steeper learning curve than others. For beginners, it's beneficial to start with a language that has a gentle learning curve and is easy to understand.
Community and Support: A large, active community makes it easier to find solutions to common problems and learn best practices. Consider languages with extensive documentation and support resources.
Platform Compatibility: Ensure the language you choose is compatible with the platforms you intend to target, such as web, mobile, or desktop applications.
Personal Preference: Finally, your personal preferences and interests will play a role in your decision. Choose a language that you enjoy working with and feel motivated to learn.

Popular Programming Languages and Examples

To give you a better idea of what different programming languages look like, let's examine a simple task: printing "Hello, World!" in several popular languages.

Python

Python is known for its readability and ease of use, making it an excellent choice for beginners.

print("Hello, World!")

Strengths: Python is widely used in web development, data analysis, artificial intelligence, and automation. Its clear syntax and extensive library support make it a versatile and popular language among developers.
Use Cases: Web applications (Django, Flask), data analysis (Pandas, NumPy), machine learning (TensorFlow, scikit-learn), automation scripting.

JavaScript

JavaScript is the primary language for web development and is essential for creating interactive web pages.

console.log("Hello, World!");

Strengths: JavaScript is executed in the browser, allowing for dynamic, responsive websites. With the rise of Node.js, JavaScript has also expanded to server-side development, increasing its versatility.
Use Cases: Front-end web development (React, Angular, Vue), back-end web development (Node.js, Express), mobile app development (React Native, Ionic).

Java

Java is a versatile language widely used in enterprise applications, Android app development, and web applications.

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}

Strengths: Java is platform-independent, meaning it can run on any device with a Java Virtual Machine (JVM). Its strong object-oriented programming (OOP) support and extensive libraries make it suitable for large-scale applications.
Use Cases: Android app development, web applications (Spring, JavaServer Faces), enterprise applications, desktop applications.

Ruby

Ruby is another beginner-friendly language, popular for web development with the Ruby on Rails framework.

puts "Hello, World!"

Strengths: Ruby boasts an elegant, readable syntax and a strong focus on simplicity and productivity. The Ruby on Rails framework has made it popular for rapid web development.
Use Cases: Web applications (Ruby on Rails, Sinatra), scripting, and automation.

C++

C++ is a powerful language with a steeper learning curve, often used in system programming, game development, and performance-critical applications.

#include <iostream>

int main() {
std::cout << "Hello, World!" << std::endl;
return 0;
}

Strengths: C++ offers low-level memory manipulation and excellent performance, making it suitable for performance-critical applications. It is also an extension of the C language, offering object-oriented programming features.
Use Cases: System programming, game development (Unreal Engine), embedded systems, high-performance applications.

Swift

Swift is Apple's programming language, designed for developing iOS and macOS applications. If you're interested in creating apps for the Apple ecosystem, Swift should be your go-to language.

print("Hello, World!")

Strengths: Swift offers modern, concise syntax, and strong performance. It is designed to be safe, fast, and easy to read, making it popular among developers building apps for Apple devices.
Use Cases: iOS app development, macOS app development, server-side development (Vapor, Kitura).

Kotlin

Kotlin is a modern language that runs on the Java Virtual Machine (JVM). It has gained popularity for Android app development as an alternative to Java, offering more concise and expressive syntax.

fun main() {
println("Hello, World!")
}

Strengths: Kotlin is interoperable with Java, allowing developers to use both languages in a project. It offers concise, expressive syntax and several modern language features, making it more enjoyable to work with than Java for many developers.
Use Cases: Android app development, web applications (Ktor, Spring Boot), desktop applications, server-side development.

Go (Golang)

Go, also known as Golang, is an open-source programming language developed by Google. It's designed for efficient, high-performance software and is particularly suitable for concurrent programming and networked applications.

package main

import "fmt"

func main() {
fmt.Println("Hello, World!")
}

Strengths: Go is known for its simplicity, strong performance, and efficient concurrency handling. It is designed for modern software development and excels in networked and distributed systems.
Use Cases: Microservices, web servers, networking tools, distributed systems, containerization (Docker).

C# (C Sharp)

C# is a versatile language developed by Microsoft, often used in the development of Windows applications, web services, and games (using the Unity game engine).

using System;

class HelloWorld {
static void Main() {
Console.WriteLine("Hello, World!");
}
}

Strengths: C# is a powerful, statically-typed language with strong support for object-oriented programming. It is tightly integrated with the .NET framework, making it ideal for Windows applications and services.
Use Cases: Windows applications, web applications (ASP.NET), game development (Unity), and cross-platform mobile app development (Xamarin).

Comparing Popular Programming Languages: Strengths, Weaknesses, and Ease of Learning

Language	Strengths	Weaknesses	Ease of Learning
Python	Readable syntax, versatile, extensive libraries	Slower performance, limited mobile app development	Easy
JavaScript	Web development, dynamic websites, server-side (Node.js)	Weakly typed, security concerns	Easy
Java	Platform-independent, strong OOP support, versatile	Verbose syntax, slower than C++	Moderate
Ruby	Elegant syntax, rapid web development (Ruby on Rails)	Slower performance, less popular than Python, JS	Easy
C++	Low-level memory manipulation, high performance	Steeper learning curve, complex syntax	Difficult
Swift	Modern syntax, Apple ecosystem, strong performance	Limited to Apple platforms	Moderate
Kotlin	Java interoperability, modern features, concise syntax	Smaller community, less mature than Java	Moderate
Go (Golang)	Simple syntax, high performance, efficient concurrency	Limited use cases, less mature than alternatives	Moderate
C#	Powerful, .NET integration, versatile	Limited cross-platform support, tied to Microsoft	Moderate

Tips for Learning Your Chosen Programming Language

Practice Regularly: Consistent practice is key to becoming proficient in any programming language. Set aside time each day or week to work on coding exercises and projects.
Start Small: Break down complex tasks into smaller, manageable parts. Build simple projects and gradually work your way up to more challenging ones as your skills develop.
Ask for Help: Don't be afraid to ask questions or seek help from others. Join programming forums, communities, or social media groups to connect with experienced developers and fellow learners.
Read Code: Reading code written by others can help you learn new techniques, best practices, and understand different programming styles.
Stay Curious: Keep exploring new concepts, libraries, and tools. This will not only enhance your skills but also help you stay engaged and motivated in your learning journey.

Remember that patience, persistence, and a passion for learning are essential for mastering any programming language.

Resources for Learning and Practicing Programming

Below is a list of resources where users can learn more and practice code development:

Codecademy - An interactive platform that offers hands-on coding courses in various programming languages.
freeCodeCamp - A non-profit organization that provides a comprehensive curriculum and hands-on projects to learn web development.
Coursera - A platform that offers a wide range of programming courses and specializations from top universities and institutions.
edX - Another platform offering programming courses from top universities, covering various languages and development techniques.
LeetCode - A platform for practicing coding problems, focusing on data structures and algorithms, to help users prepare for technical interviews.
HackerRank - A website that offers coding challenges and competitions in various domains, including algorithms, artificial intelligence, and databases.
Codewars - A community-driven platform where users can improve their programming skills by solving coding challenges known as "kata."
MDN Web Docs - A comprehensive resource for web developers, offering tutorials, guides, and reference materials for HTML, CSS, and JavaScript.
W3Schools - A popular web development tutorial site, covering a wide range of topics like HTML, CSS, JavaScript, Python, and more.

These resources offer valuable learning materials, hands-on practice opportunities, and supportive communities to help users improve their programming skills and build confidence in their abilities.

Making Your Decision

By considering your career goals, learning curve, community support, platform compatibility, and personal preferences, you'll be better equipped to choose the right programming language for your needs. Additionally, the code examples provided should help illustrate the differences between these popular languages.

Remember, there's no one-size-fits-all answer, and many developers eventually learn multiple languages throughout their careers. The most important thing is to start learning and never stop growing your skills.

Good luck on your programming journey! 😀

Runtime encrypted strings: Part 1

Mecanik1337 — Tue, 06 Oct 2026 06:00:00 +0000

Runtime Encrypted Strings

Today we will go through the basics of runtime encrypted strings, why do we need to encrypt our strings and learn how to create our own.

In this article you will understand and learn:

What is runtime encryption and decryption
Why do you need to encrypt your strings
See how anybody can see your sensitive data
Create your own custom encryption

What is runtime encryption and decryption

This refers to data encrypted and/or decrypted during the runtime of a program (software, application). The data can be of any type from memory blocks, network traffic, strings, etc.

One of the most common methods used for this purpose is obfuscation (basic). The other (advanced) mechanisms involve mutation/virtualization of compiled code.

Today we will focus on a mechanism using XOR obfuscation.

Why encrypt strings?

The moment you run your software everything is visible in memory. This applies to your end users as well which means they can see everything.

One of the first things an attacker will do is look for strings inside your software. This will allow him to understand everything about your software with minimal effort.

If you are storing sensitive data (like passwords or licenses) it is crucial to not keep them in plain text. Keeping them in plain text will make the life of an attacker easy.

There is a number of ways people can use to analyze your software. The most known and common methods are static and runtime analysis.

Let’s have a look at a simple example using a console app:

We compile this in Release mode (to avoid any debug information left inside). Let’s proceed and test the static and runtime analysis.

Static Analysis Test

In static analysis the software does not need to execute. With that said, let’s open the sample in Ghidra.

From the screenshot below you can see that the sample is compiled without any debug information:

If we search for strings you can see that all our sensitive information is visible:

Once you highlighted the string you can open the decompiler view and see all the relevant code:

Pretty sad eh? 😕 Imagine you worked on your amazing software for months, and you are ready to sell it.

I think the rest is self-explanatory, but I’m sure you get the point.

What’s even sadder is the fact that this is so simple that even a 12-year old can do it. (and some actually do it)

Runtime Analysis Test

In runtime analysis the software needs to run (execute). This means we need to use a software to open the process and read it (normally a debugger).

However, a debugger is not really needed for this purpose. We can simply download a free tool like Process Hacker and open the process:

That was rather simple right? And keep in mind that we haven’t even attached a debugger. A skilled and determined individual will use a debugger.

When you attach a debugger you see much more, but that discussion is for another day.

Creating Runtime Encrypted Strings

There are numerous ways you achieve this:

Using a third party software like VMProtect, Themida.
Compile time string encryption like xorstr.
Using custom methods

The first 2 options might not suit your needs. There are many ups and downs for each of them, which we will not discuss at this point.

One thing you need to understand is that popularity means risk. When you use stuff found randomly on Google, someone already knows about it.

Most people developed a tool against your tool. It’s just the way things are. They do it for a challenge, or to steal your work, but they do it.

With this in mind, you must go custom. You can create your own string encryption from basic to advanced level.

The Plan

Create an easy to use solution
Keep strings encrypted at all times
Decryption only when you need it
Place the strings in random location (optional – not covered)
Destroy the strings after using them (optional – not covered)

The Solution

Start by defining our strings one by one as an array:

The array can hold an unlimited number of strings with a 256 length limit.

I know this is a daunting task, especially if your strings are long. This is just for demonstration and later on we will create a more practical solution.

The idea is to encrypt each character from the string. I will use a simple XOR encryption for this.

Below you can see an example of how this would work:

The above has nothing complicated going on, it’s plain and simple yet quite powerful. You can use this inside a console application.

After you compile and run, the result is unreadable bytes to the human eye:

There you have it, your own little software to create runtime encrypted strings. 😏

The Result

I’s time to put our solution into practice. Let’s create another sample for this purpose and add our code:

Notice 2 important things:

I’ve left some strings in plain text so you can see the difference
The decryption functions needs the length (more on this later)

We compile the above in Release mode and run it. The new Sample is working normally:

If we open the new Sample software in IDA (or Ghidra) the strings we encrypted are not visible:

I’ve mentioned that there are some string intentionally left plain in this sample. The reason why is, so we can follow them to see the code:

I had to scroll down to reach the text in the above image. You can see how different the compiled code is.

We solved the static analysis problem, let’s move on to runtime.

Open it in Process Hacker:

Voila! We solved the runtime analysis problem as well 😎

More on encrypted strings

The above example is not very practical. Defining each string manually is a daunting task, as well as specifying the length of the string each time.

Ideally we would need the following:

Reading a text file for strings
Writing to a text file the resulted strings
Adding the Escape sequences to strings to avoid specifying the length each time.
Add more complex XOR or any other method (optional)
Place the strings on random locations (optional)

I have prepared a nice solution for you to play with. You can test everything written in this article and also have your own ready to use tool to make runtime encrypted strings.

It includes 4 projects:

RuntimeStringEcryptor which reads from a text file strings, encrypts them and then writes them to another text file.
Sample is the plain simple console used to demonstrate with IDA.
SampleEncryptedStrings is the simple console with encrypted strings to demonstrate with IDA.
SimpleRuntimeStringEncryption is the initial playground where you can test this method.

Notes:

If you don’t add escape sequence, the decryption will not know when to “stop”. The result being in gibberish/null data until it reaches the defined array size.
Make sure you change the XOR keys I have used in my example.
Avoid using the same words multiple times. They will generate the same bytes and it’s a risk of being detected.

DeepSeek R1 vs. OpenAI o3-mini: Which API is Best?

Mecanik1337 — Mon, 05 Oct 2026 18:00:00 +0000

Choosing between DeepSeek R1 vs OpenAI o3-mini is a critical decision for developers integrating reasoning APIs into software applications in 2026. When it comes to reasoning APIs, these are the two strongest candidates most teams end up weighing. Both models excel at complex tasks, code generation, mathematical analysis, and structured logic. However, they operate on different pricing structures, reasoning token methods, latency patterns, and structured data validation limits. This guide compares the two in detail to help you choose the best API for your developer workflows.

TL;DR

Understand reasoning models; reasoning models utilise "thinking tokens" to solve problems before returning a response, improving accuracy on logical tasks.
DeepSeek R1 is highly cost-effective; R1 offers open-source weights and extremely low API costs, making it ideal for high-volume execution.
OpenAI o3-mini delivers lower latency; o3-mini excels at rapid, real-time responses and features robust structured JSON-schema support.
Evaluate data portability; R1 can be hosted on your own cloud infrastructure, preventing vendor lock-in, while o3-mini is hosted exclusively on OpenAI.
Select based on task requirements; use o3-mini for interactive, real-time web applications, and R1 for bulk analytical workflows and offline data processing.

The Core Concept of Reasoning Models

Unlike standard chat completion models, reasoning models are trained to think step by step before outputting answers.

This reasoning process utilises specialised "thinking tokens." The model generates internal steps to cross-examine its assumptions, debug code, and analyse syntax. While this process improves the quality of responses on complex logical tasks, it increases response latency and token costs. Understanding how to manage these context sizes is essential for budgeting. To see how standard APIs differ from reasoning ones, read our guide on building an OpenAI API chatbot.

Latency vs. Reasoning Depth

In production, latency is a critical consideration. If your application requires real-time user interaction, slow API responses will harm the user experience.

OpenAI's o3-mini is optimised for speed. It returns complex reasoning answers in a fraction of the time required by larger models, making it ideal for interactive coding tools. In a head-to-head speed test, o3-mini comes out faster, while DeepSeek R1 prioritises reasoning depth. It writes longer internal reasoning steps, which can result in longer response times. To inspect how to handle edge compute limits and latency, read our comparison of Cloudflare Workers vs AWS Lambda.

Structured Outputs and JSON Parsing

When integrating AI into software workflows, receiving unstructured text is problematic. You must ensure the model returns structured data, such as JSON schemas, to integrate with your database.

OpenAI o3-mini supports structured outputs with strict JSON schemas. This feature guarantees that the API response matches your specified JSON schema exactly, eliminating parsing errors. DeepSeek R1 also supports JSON formats, but developers must write clear system instructions and handle validation checks manually. If you are building database integrations, we suggest linking these APIs to edge databases; see Cloudflare D1 serverless database setup for details.

Pricing and Cost Optimisation

API usage costs are a primary consideration when scaling AI applications. The table below highlights the key pricing differences between the two APIs.

Model API	Input Cost (per 1M tokens)	Output Cost (per 1M tokens)	Hosting Flexibility
OpenAI o3-mini	Higher	Moderate	Hosted only (proprietary)
DeepSeek R1	Extremely Low	Extremely Low	Portable (open weights)

DeepSeek R1 is highly cost-effective, providing reasoning capabilities at a fraction of the cost of proprietary alternatives. Furthermore, since R1 weights are open, you can host the model on your own hardware or deploy it to edge runtimes; see our Cloudflare Workers AI tutorial to learn how to deploy models serverless.

How the Two Reasoning APIs Compare at a Glance

The headline choice comes down to a handful of dimensions that actually affect an integration: how much context each model accepts, how it handles structured data, where it can run, and what a request costs. The table below summarises the practical differences. Treat the specific figures as illustrative snapshots. Published limits and rates for both APIs change frequently, so confirm the current numbers in each provider's documentation before you commit.

Dimension	OpenAI o3-mini	DeepSeek R1
Context window (typical)	~200K tokens	~64K tokens
Max output per request	~100K tokens	~8K–32K tokens
Structured outputs	Native strict JSON schema	JSON via prompting + manual validation
Reasoning-effort control	Adjustable (low/medium/high)	Fixed reasoning behaviour
Hosting	OpenAI cloud only	Hosted API or self-hosted (open weights)
Relative latency	Lower	Higher (longer reasoning traces)
Relative token price	Higher	Substantially lower
Best-fit workload	Interactive, real-time tools	High-volume, batch analysis

Two rows deserve extra attention. o3-mini exposes a reasoning-effort setting, so you can dial thinking down for simple calls and up for hard ones, a direct lever on both latency and cost. R1's open weights, by contrast, mean the same model can run inside your own network, which matters for data-residency and compliance requirements that a hosted-only API cannot satisfy.

Working Out the Cost per 1,000 Calls

Per-million-token rates are hard to reason about in isolation, so it helps to work a realistic scenario end to end. Imagine a classification service that enriches each support ticket: roughly 800 input tokens of prompt and context, and 1,200 output tokens per reply, of which perhaps 900 are internal thinking tokens and 300 the visible answer. Reasoning models bill those thinking tokens at the standard output rate, so they count in full.

Using illustrative published rates (o3-mini around $1.10 input and $4.40 output per million tokens; R1 around $0.55 input and $2.19 output per million), the arithmetic works out as follows:

Step	OpenAI o3-mini	DeepSeek R1
Input: 800 tokens	$0.00088	$0.00044
Output: 1,200 tokens	$0.00528	$0.00263
Cost per call	~$0.0062	~$0.0031
Cost per 1,000 calls	~$6.16	~$3.07
Cost at 1M calls/month	~$6,160	~$3,070

At this shape of workload the hosted R1 API lands at roughly half the running cost of o3-mini. The gap widens as output tokens grow, because reasoning-heavy prompts spend most of their budget on the more expensive output side. The lesson is to estimate output tokens, thinking included, rather than input, since that is where reasoning-model bills are won or lost. Capping maximum output tokens and lowering reasoning effort on easy calls are the two most effective controls.

Self-hosting R1 changes the equation again: you swap per-token fees for GPU rental. A high-memory GPU instance capable of serving the full model tends to run into the low thousands of pounds per month, so self-hosting only beats the API once sustained throughput is high enough to keep that hardware busy. Below that break-even point, the managed API is cheaper and far less operational work.

Choosing by Workload, Not by Winner

Neither model is universally "better"; the right pick follows the shape of the job.

Choose OpenAI o3-mini when the interaction is user-facing and latency is visible: coding assistants, chat features, autocomplete, or anything where a person waits for the response. Its native strict JSON schema also makes it the safer choice when a malformed response would break a downstream system, such as a function-calling agent or a database write. The adjustable reasoning effort lets one integration serve both quick and hard queries without swapping models.

Choose DeepSeek R1 when volume is high and latency is hidden: overnight batch jobs, document enrichment, bulk classification, dataset labelling, or offline analysis where throughput and unit cost matter more than a second or two of delay. It is also the pragmatic choice under strict data-governance rules, because the open weights let you keep every token inside infrastructure you control.

Many production stacks end up using both: a fast hosted model on the interactive path and a cheaper, self-hostable model on the batch path, with a routing layer that sends each request to the model that fits. That hybrid pattern captures most of the cost saving without sacrificing the responsiveness users notice.

Total Cost of Ownership and Switching Costs

Sticker price is only part of the total cost of ownership. Because both APIs speak a broadly OpenAI-compatible request format, moving a prompt from one to the other is usually a matter of changing the endpoint, key, and model name rather than rewriting application logic. That keeps switching costs low and is a strong argument for not hard-coding a single provider. The larger migration effort sits elsewhere: strict-schema features and reasoning-effort parameters are provider-specific, so any code that depends on them needs a fallback path when you move to a model that lacks them.

Factor in the softer costs too. A hosted API adds no operational burden but exposes you to rate limits, pricing changes, and regional availability. Self-hosting removes those risks but adds GPU provisioning, scaling, patching, and monitoring, all real engineering time that belongs in the budget. Abstracting the model call behind a thin internal interface from day one is the cheapest insurance: it lets you test the two APIs against each other on your own traffic and switch whenever price or performance shifts, which for fast-moving reasoning models it inevitably will.

Key Takeaways

Reasoning models use internal thinking tokens to solve logical problems, outperforming standard chat models.
OpenAI o3-mini is optimised for low-latency, real-time web applications requiring structured JSON formats.
DeepSeek R1 is highly cost-effective and portable, allowing self-hosting to prevent vendor lock-in.
Choose o3-mini for interactive development assistants; choose R1 for high-volume offline data analysis.
Manage reasoning token sizes carefully to prevent unexpected API costs in production.

Integrate Reasoning Models into Your Stack

Integrating advanced reasoning APIs requires careful prompt engineering, error handling, and hosting configurations. Mecanik provides professional AI integration services and custom setups through our OpenAI API integration service. We construct fast, secure AI pipelines tailored to your business. Contact us today to discuss your next project.

Frequently Asked Questions (FAQ)

What is the difference between a reasoning model and a standard model?
Reasoning models use internal thinking tokens to analyse problems and debug logical steps before outputting a response, whereas standard models predict the next token immediately.

Can I host DeepSeek R1 on my own servers?
Yes. DeepSeek R1 is an open-source model with public weights, allowing you to self-host it on your own GPU infrastructure or deploy it on serverless runtimes.

Does OpenAI o3-mini support strict JSON schemas?
Yes. OpenAI's API supports structured outputs, guaranteeing that the model's output conforms exactly to the JSON schema you define in the API call.

How does thinking token usage impact API costs?
Thinking tokens are billed as input and output tokens. Because the model must write out its internal reasoning steps, a single query uses more tokens than a standard API query.

Which model is better for code generation?
Both are excellent. OpenAI o3-mini is faster and more interactive, while DeepSeek R1 often provides deeper logic analysis on complex, multi-file software tasks.

Deploying Llama 3 on the Edge with Cloudflare Workers AI

Mecanik1337 — Mon, 05 Oct 2026 06:00:00 +0000

This Cloudflare Workers AI tutorial shows you how to deploy and run machine learning models directly on Cloudflare's global edge network. With Cloudflare Workers AI, you can execute Large Language Models (LLMs), text translation, image generation, and audio transcription close to your users without managing complex GPU servers. The steps below cover how to configure Wrangler, write a fetch handler, run a Llama model, and optimise API costs at the edge.

TL;DR

Run AI models serverless; Cloudflare Workers AI manages the underlying GPU infrastructure, billing you only for active compute.
Configure bindings in wrangler.toml; link your worker directly to the AI binding without managing API keys.
Write a fetch handler to receive user requests, execute the model, and stream JSON responses.
Select optimised models from Cloudflare's catalogue (such as Llama 3, Whisper, or Stable Diffusion) to balance speed and accuracy.
Silo billing and rate limits to protect your endpoint from high-token cost abuse in production.

Why Run AI Models on the Edge?

Traditionally, integrating AI features required calling external APIs (like OpenAI) or hosting open-source models on expensive cloud servers.

Calling external APIs presents latency and data privacy concerns. Running your own GPU servers introduces maintenance challenges and scales poorly. Cloudflare Workers AI resolves this dilemma. The platform hosts open-source models on GPUs deployed across Cloudflare's global network. Your code runs as a lightweight Worker, executing models close to your users with near-zero latency. For an introduction to building basic edge structures, check our guide on building a serverless API with Cloudflare Workers.

Prerequisites

Before you begin, make sure you have the following in place:

A Cloudflare account with Workers enabled. The free plan includes a daily inference allocation, which is more than enough to follow this guide.
Node.js 18 or newer installed locally, so you can run the tooling and the local development server.
Wrangler, the Workers CLI, installed and authenticated. Install it with npm install -g wrangler, then run wrangler login to link it to your account.
Basic familiarity with JavaScript and the fetch request/response model that every Worker is built around.

If you are starting from a blank slate, scaffold a project with the create-cloudflare (C3) tool. It generates a ready-to-deploy Worker, a wrangler.toml, and a sensible compatibility_date:

npm create cloudflare@latest my-edge-ai
cd my-edge-ai

Choose the "Hello World" Worker template when prompted. That gives you a clean starting point to which you can add the AI binding in the next step.

Step 1: Configuring wrangler.toml

To access AI models, you first need to define the AI binding in your project's configuration file.

Open your wrangler.toml (or wrangler.json) and add the following block:

[ai]
binding = "AI"

This binding makes the AI service available on the environment argument (env.AI) in your worker code. You do not need to manage API keys, configure endpoints, or deal with connection strings. Wrangler handles the authentication automatically when you deploy.

A complete wrangler.toml for this project looks like this:

name = "my-edge-ai"
main = "src/index.js"
compatibility_date = "2025-01-01"

[ai]
binding = "AI"

The compatibility_date matters: it pins runtime behaviour so future platform changes cannot silently alter how your Worker runs. Omit it and deployment fails with a configuration error, which is one of the most common first-run stumbles.

Step 2: Writing the Worker Code

Once the binding is configured, you can call the AI service from your fetch handler. The example below shows how to receive a JSON payload containing a user prompt and generate a text completion using Llama 3.

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    try {
      const { prompt } = await request.json();
      if (!prompt) {
        return Response.json({ error: "Missing prompt" }, { status: 400 });
      }

      // Call the model using the AI binding
      const response = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
        prompt: prompt,
        max_tokens: 256
      });

      return Response.json(response);
    } catch (err) {
      return Response.json({ error: err.message }, { status: 500 });
    }
  }
};

This simple structure allows you to build text summarisers, sentiment analysis tools, or content generators. If you want to connect these features to your database, you can bind to a serverless SQL database; see Cloudflare D1 database setup for details.

Using the chat message format

The prompt field is convenient for one-shot completions, but conversational models behave best with a structured messages array. This lets you set a system instruction that shapes the model's tone and keep it separate from the user's input:

const messages = [
  { role: "system", content: "You are a concise technical assistant." },
  { role: "user", content: prompt }
];

const response = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
  messages,
  max_tokens: 512
});

// Text models return the generated text on the `response` property
return Response.json({ answer: response.response });

Note that text-generation models wrap their output in a response field, so the completed text lives at response.response rather than at the top level. This catches out many first-time users, who log the raw object and see an unexpected shape.

Choosing the Right Model

Cloudflare's catalogue includes dozens of models, and choosing well is a trade-off between speed, quality, and cost. Smaller models reply faster and consume fewer resources; larger models reason better but cost more per request. The table below compares a few popular text-generation options.

Model	Best for	Relative speed	Relative cost
`@cf/meta/llama-3-8b-instruct`	General chat, summarisation	Fast	Low
`@cf/meta/llama-3.1-70b-instruct`	Complex reasoning, longer answers	Slower	Higher
`@cf/mistral/mistral-7b-instruct-v0.2`	Lightweight instructions, drafts	Fast	Low
`@cf/meta/llama-guard-3-8b`	Moderating and classifying content	Fast	Low

As a rule of thumb, start with an 8B model such as Llama 3 8B Instruct. It handles the majority of summarisation, classification, and chat workloads at a fraction of the latency and cost of a 70B model. Only move up to a larger model once your own evaluations show the smaller one genuinely falling short.

Step 3: Streaming Responses for Better User Experience

For chat applications, waiting for the full response to generate can result in poor user experience.

You can configure the AI binding to stream the response token by token as it generates. To achieve this, pass stream: true in your request options. The worker will return a ReadableStream that you can forward directly to the browser client, creating a fast, interactive chat interface. To compare this edge runtime approach with traditional cloud hosting, read our comparison of Cloudflare Workers vs AWS Lambda.

Here is a complete streaming handler. Rather than returning parsed JSON, you forward the stream to the client with the correct content-type so the browser can consume it as Server-Sent Events:

export default {
  async fetch(request, env) {
    const { prompt } = await request.json();

    const stream = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
      prompt,
      max_tokens: 512,
      stream: true
    });

    return new Response(stream, {
      headers: { "content-type": "text/event-stream" }
    });
  }
};

The key difference from the non-streaming version is the response itself: you pass the stream straight into new Response() and set content-type to text/event-stream. Wrap a stream in Response.json() instead and it will not serialise correctly, so the client receives an empty body.

Testing and Deploying Your Worker

With the binding and handler in place, run the Worker locally before you ship it:

npx wrangler dev

Because inference runs on Cloudflare's GPUs rather than on your machine, the AI binding reaches out to the network even during local development. Wrangler manages this for you, but it does mean local testing needs connectivity and a valid login to work.

Send a test request with curl while wrangler dev is running:

curl -X POST http://localhost:8787 \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Summarise the benefits of edge computing in one sentence."}'

Once you are happy with the output, deploy to the global network:

npx wrangler deploy

Wrangler uploads your Worker and returns a *.workers.dev URL. Your endpoint is now live in every Cloudflare data centre, and each request is routed to the location closest to the user automatically.

Common Pitfalls and Troubleshooting

A handful of issues recur when teams first deploy inference at the edge. Knowing the fix in advance saves hours of debugging.

Cannot read properties of undefined (reading 'run') — the env.AI binding is undefined. This almost always means the [ai] block is missing from wrangler.toml, or you edited the file but did not restart wrangler dev (or redeploy). Confirm the binding name matches exactly.
No such model or a 400 error on run — the model identifier is wrong. Model names are case-sensitive and must include the full path, for example @cf/meta/llama-3-8b-instruct. Copy them from the model catalogue rather than typing from memory.
Empty or malformed streamed responses — you returned the stream through Response.json() instead of new Response(stream, ...). Streams must be forwarded, not serialised.
Capacity or 429 errors under load — the model is temporarily saturated or you have hit an account limit. Add a short retry with back-off, and consider a smaller model for bursts of traffic.
Truncated answers — the reply stops mid-sentence because max_tokens is too low. Raise the limit, but remember that larger values increase both latency and cost.

If a request fails silently, watch the live logs with npx wrangler tail while you send a test request. It streams runtime errors and console.log output from the deployed Worker, which is the quickest way to see what the model actually returned.

Optimising Production Costs and Security

While Workers AI is highly cost-effective, running model inference in production requires careful controls.

Implement Rate Limiting: Limit how often a client can call your endpoint. GPU compute costs scale with usage.
Sanitise Prompts: Validate inputs to prevent injection attacks and ensure the model outputs stay on brand.
Silo Context Size: Keep prompt histories short. Sending massive context buffers on each call increases token processing costs.

For a detailed look at context management, check our guide on building an OpenAI API chatbot.

Key Takeaways

Cloudflare Workers AI provides serverless access to open-source models without GPU maintenance.
Configure access by adding the [ai] binding block to your wrangler.toml.
Write fetch handlers to execute text generation, translation, or image tasks directly at the edge.
Enable token streaming with stream: true to optimise mobile and chat experiences.
Implement rate limits and prompt sanitisation to protect your edge endpoints in production.

Build Your AI Applications on the Edge

Building reliable AI integrations requires expert knowledge of serverless architecture. Mecanik specialises in AI integration services and custom API setups through our OpenAI API integration service. We build edge-native tools that scale seamlessly, optimising costs and user experiences. Contact us today to discuss your project requirements.

Frequently Asked Questions (FAQ)

What is Cloudflare Workers AI?
It is a serverless platform that allows you to run machine learning models (text generation, translation, speech-to-text, image generation) on Cloudflare's global GPU network.

Do I need an API key to use Workers AI?
No. Once you declare the AI binding in your wrangler.toml file, Cloudflare handles credentials internally, making the service accessible via env.AI as shown in this cloudflare workers ai tutorial.

What models are available on Cloudflare Workers AI?
The platform hosts popular open-source models, including Meta Llama, Mistral, OpenAI Whisper, and Stable Diffusion, which are updated regularly in their model catalogue.

Can I stream text responses from Workers AI?
Yes. By setting stream: true in the parameters of your env.AI.run call, the worker returns a standard ReadableStream to stream text to the browser.

How does billing work for Workers AI?
Billing is based on the number of tokens processed (for text models) or the duration of compute time (for other models), offering a cost-effective utility model.

Drupal Migration in 2026: Costs, Options and Deadlines

Mecanik1337 — Sun, 04 Oct 2026 18:00:00 +0000

Drupal migration is one of those projects that stays comfortably in next quarter's plan until a date makes it urgent. Two dates are doing that right now, and only one of them is in the future.

Drupal 7 lost official support on 5 January 2025. Any site still running it has been going without security coverage for well over a year. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released, after which it receives no further releases of any kind. If you are on either version, the question is no longer whether to move but which path to take and what it will cost.

Where you stand: From Drupal 10 to Drupal 11 is a genuine upgrade — the same site, updated in place, typically two to six weeks. From Drupal 7 to Drupal 11 is not an upgrade at all; it is a rebuild with a content migration attached, and it typically runs three to six months. Confusing the two is the single most expensive mistake in this space, because Drupal 7 sites get quoted as upgrades and then overrun by a factor of four.

The Two Very Different Migrations

The word migration covers two jobs that share almost nothing beyond the name.

Drupal 10 to 11 is an upgrade. The architecture is the same. Your entities, fields, views and configuration carry across. The work is mostly dependency management: making sure every contributed module has a Drupal 11 compatible release, clearing deprecated API calls out of your custom code, and moving to a supported PHP version. It is methodical rather than difficult, and a well-maintained site can be done in a fortnight.

Drupal 7 to Drupal 11 is a rebuild. Drupal 8 rewrote the platform on Symfony components, replacing the module API, the theming layer and the configuration system. Nothing carries over automatically except content, and even that arrives through a purpose-built migration process rather than an upgrade script. Your modules do not exist any more, your theme has to be rewritten in Twig, and your custom code has to be reimplemented against a different architecture.

That second case is why Drupal 7 sites have lingered so long. The honest framing is that you are not upgrading a site, you are building a new one and bringing the content with you.

What Each Drupal Migration Path Costs

Figures below assume UK agency rates and a site of moderate complexity. Complexity here means the number of content types, contributed modules and custom modules, not the number of pages.

Drupal 10 to 11, well-maintained site. Two to four weeks, roughly £6,000 to £15,000. This is the happy case: modules are current, custom code is small, and the main work is testing.

Drupal 10 to 11, neglected site. Four to eight weeks, roughly £15,000 to £35,000. Here the blockers are contributed modules with no Drupal 11 release, custom code written against APIs that have since been removed, and a PHP version that also has to move. Every abandoned module becomes a decision: find a replacement, take over maintenance, or reimplement its behaviour.

Drupal 7 to Drupal 11. Three to six months, commonly £40,000 to £120,000 and higher for large or heavily customised sites. That range is wide because it is really a rebuild budget. The content migration itself is often the smaller half; the theme, the custom functionality and the integrations are the larger half.

Drupal 7 to a different platform. Sometimes the right answer. If the original reason for choosing Drupal no longer applies — the site has become a straightforward marketing site with a blog — then moving to something simpler can cost less than migrating within Drupal, and reduce running costs afterwards. Our comparison of WordPress and custom web development covers where that line sits, and the Drupal web development guide is honest about when Drupal is not the answer.

Why Contributed Modules Decide Your Timeline

Almost every Drupal upgrade estimate lives or dies on the contrib audit, and it is the first thing worth doing.

List every contributed module the site uses, then check each one for a stable release compatible with your target version. What you will find falls into four groups. Some have a compatible release and need nothing. Some have a release candidate or a patch in the issue queue that you can apply through Composer. Some have been abandoned, and you must find a replacement, adopt the module yourself, or replace its function with custom code. And some have been absorbed into Drupal core, which is the pleasant surprise of the exercise.

That audit converts a vague project into a countable one. Until it is done, any quote is a guess, and a supplier who gives you a fixed price without it is either padding heavily or about to raise change requests.

The same logic applies to custom modules, with a different tool. Drupal's deprecation tooling will scan custom code and report calls to APIs that have been removed or are due for removal, which turns "we have some custom code" into a specific list of files and line numbers.

What Actually Goes Wrong

Certain failure modes recur across almost every Drupal migration.

Configuration drift between environments. If changes have been made directly in the production admin interface rather than exported to configuration files, your staging environment is not a faithful copy and your testing is worth less than you think. Discovering this mid-migration is common and it always costs time.

Content that was never as structured as everyone believed. Drupal 7 sites frequently accumulated content in ways nobody documented: fields repurposed for other things, a taxonomy vocabulary doing the job of a workflow state, HTML pasted into body fields carrying inline styles. A migration surfaces all of it at once, and each case needs a decision from someone who knows what the content is for.

Media and file handling. Drupal's media handling changed substantially after Drupal 7. Files, image styles and embedded media rarely map one to one, and sites with large media libraries should budget for this specifically rather than assuming it comes free with the content migration.

URL and SEO continuity. This is the one that damages the business rather than the schedule. If URL aliases change without redirects, you lose the rankings the old site earned. Every migration needs a full URL inventory, a redirect map, and verification after launch. Our guide to migrating a website without losing traffic covers that process in detail, and it applies to platform changes just as much as domain changes.

Multilingual content. If the site runs in several languages, expect the migration to take substantially longer. Language handling was rebuilt after Drupal 7, and translated content, translated configuration and language-specific URL patterns each need their own attention.

How to Sequence the Work

The order matters more than most teams expect, and getting it wrong causes rework.

Start with the contrib and custom code audit, before any estimating. Then get the site onto a supported PHP version and the latest release of its current major version, because that removes a whole category of noise from the actual upgrade. Only then attempt the major version step.

Build the new environment alongside the old one rather than upgrading in place. That gives you somewhere to test the content migration repeatedly, which you will need, because migrations are run many times before they are run once for real.

Treat the content migration as code. Drupal's migration framework lets you define migrations in configuration and re-run them, which means you can reset, adjust the mapping and go again. Teams that hand-fix content in the new site rather than fixing the migration definition end up unable to re-run it, and then a single content change in the old site becomes a manual reconciliation.

Finally, plan a content freeze near the end, and keep it short. Long freezes cause editors to work around you, which produces exactly the drift you were trying to avoid.

Should You Move Off Drupal Entirely?

It is a fair question and it deserves an honest answer rather than a defensive one.

Stay on Drupal when the reasons you chose it still hold: complex content modelling, granular permissions, multilingual requirements, heavy editorial workflow, or accessibility and public sector obligations. Drupal remains genuinely strong at all of these and the upgrade path from here is now stable, with a predictable two-year major release cycle.

Consider moving when the site has drifted away from those needs. Plenty of Drupal 7 sites are now, in practice, a marketing site with news and a contact form. Migrating that within Drupal means paying rebuild prices for capability you no longer use.

The decision should turn on the content model and the editorial workload, not on which platform your developer prefers. If nobody can articulate what Drupal is doing for you that a simpler platform could not, that is informative.

Get the Audit Before You Get a Quote

Mecanik handles Drupal upgrades and migrations as part of our website development services. We start with the contrib and custom code audit, because that is what turns an open-ended project into a fixed scope, and it is worth having even if you then take the work elsewhere.

For Drupal 10 sites the sensible move is to plan the Drupal 11 step now rather than in November, when everyone else is doing it. For Drupal 7 sites the security position is already the argument. If your constraint is capacity rather than expertise, our guide to hiring a Drupal developer covers what to look for.

Tell us which version you are on and roughly how many contributed and custom modules the site uses, and we will tell you which of the paths above you are actually facing.

Frequently Asked Questions

When does Drupal 10 stop being supported?
Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released. After that date it receives no further releases, including security fixes, so any site remaining on it is running unsupported.

How much does a Drupal migration cost?
A Drupal 10 to 11 upgrade on a well-maintained site typically costs £6,000 to £15,000, rising to £15,000 to £35,000 where modules and custom code are neglected. Drupal 7 to Drupal 11 is a rebuild with content migration and commonly runs £40,000 to £120,000 or more.

Why is Drupal 7 to Drupal 11 so much more expensive?
Because it is not an upgrade. Drupal 8 rebuilt the platform on Symfony components, replacing the module API, theming layer and configuration system. Modules must be replaced, themes rewritten in Twig and custom code reimplemented, with content brought across through a purpose-built migration.

How long does a Drupal 10 to 11 upgrade take?
Two to four weeks for a site whose contributed modules are current and custom code is small, and four to eight weeks where abandoned modules or removed APIs have to be worked around. A contributed module audit up front is what makes the estimate reliable.

Can I migrate from Drupal to WordPress instead?
Sometimes that is the right call, particularly where a Drupal 7 site has become a straightforward marketing site with no complex content modelling, permissions or multilingual needs. Base the decision on your content model and editorial workload rather than on platform preference.

COBOL Migration Cost, Timeline and Risk - A UK Guide 2026

Mecanik1337 — Sun, 04 Oct 2026 06:00:00 +0000

"How much will it cost to move off COBOL?" is the first question every board asks, and the honest answer is that it depends on more than the size of the codebase. This guide breaks down what actually drives the cost of a COBOL migration in the UK, realistic budget and timeline ranges, and the risks that turn a well-planned project into an overrun.

TL;DR

A mid-size UK COBOL migration typically costs £200,000 to £800,000 and takes one to two years; full mainframe decommissions run into the millions and multiple years
Cost is driven far more by codebase complexity, undocumented business logic, and data access redesign than by raw line count
The choice of target language and migration approach materially changes the budget
The most common reason projects overrun is underestimating scope, especially undocumented business rules and the data access layer

What Actually Drives COBOL Migration Cost

Line count is the headline number, but it is a weak predictor on its own. The real cost drivers are:

Complexity, not just size. A 100,000-line system of clean batch programs is cheaper to migrate than a 50,000-line system dense with EXEC CICS, dynamic CALLs, and intricate REDEFINES. Transaction processing systems cost more than batch systems of the same size.

Undocumented business logic. COBOL systems often carry 30 to 40 years of business rules embedded in code with no external documentation. Rediscovering and validating those rules is frequently the single largest and least predictable line item.

The data access layer. EXEC SQL against DB2 and VSAM file handling rarely convert automatically. They must be redesigned onto the target platform's data access technology, and this is often the biggest work item after business-logic discovery.

Data format conversion. Packed decimal (COMP-3), EBCDIC encoding, and fixed-width layouts all need explicit mapping and testing with real data.

Target language and approach. These shift the budget in predictable ways (covered below).

Testing and cut-over. Building a regression test suite that proves output parity, and executing a safe cut-over with rollback, is real, non-trivial effort that inexperienced estimates omit.

Indicative Cost and Timeline Ranges (UK)

These ranges cover analysis, migration, testing, and go-live support. They exclude ongoing operational costs, training, and downstream integration work that often surfaces mid-project.

System Size	Approach	Estimated Cost	Typical Timeline
Small (< 50,000 lines)	Parallel rewrite	£80,000 to £200,000	3 to 9 months
Medium (50,000 to 500,000 lines)	Strangler fig	£200,000 to £800,000	12 to 24 months
Large (500,000+ lines)	Automated + incremental refactor	£500,000 to £2,000,000+	2 to 4 years
Legacy mainframe decommission	Full programme	£1,000,000 to £10,000,000+	3 to 5 years+

Treat these as planning ranges, not quotes. A proper estimate requires a code assessment; the spread within each band is driven by the complexity factors above.

How the Target Language Affects Cost

The destination language changes both the effort profile and the long-term cost of ownership. In broad terms:

Python maps naturally to COBOL's procedural style and has the largest developer pool, which tends to lower conversion and long-term maintenance cost.
C# is efficient for organisations already on the .NET and Azure stack, and its native decimal type reduces the effort of getting financial precision right.
Java suits JVM-based enterprises; BigDecimal handles precision correctly but adds some verbosity.
Go is efficient to build and deploy, but the lack of a native decimal type adds review effort for financial fields.
Rust tends toward the upper end of any size band because its ownership model adds up-front design effort.

The COBOL migration overview compares all six target languages side by side to help you choose.

How the Migration Approach Affects Cost

Automated conversion reduces the mechanical translation effort but never produces a finished system; budget for the manual work the tooling flags (embedded SQL, CICS, dynamic calls, decimal precision).
Parallel rewrite roughly doubles operational cost during the transition because two systems run at once, but it minimises continuity risk. It suits smaller, mission-critical systems.
Incremental (strangler fig) spreads cost over time and reduces big-bang risk, at the price of a longer hybrid period. It is the most common approach for large UK enterprise systems.

Most real projects blend automated conversion with an incremental rollout.

The Risks That Cause Overruns

Migrations overrun for predictable reasons. The big five:

Underestimated business-logic discovery. The rules are in the code, not in a document. Budget explicit discovery time.
Data access redesign. DB2 and VSAM access does not port automatically. Treat it as its own workstream.
Inadequate regression testing. Without output-parity testing on real data, you cannot prove the migration is correct. Build the test suite before migration starts.
Decimal precision errors. Financial fields mapped to floating-point types silently corrupt money. Map to the correct decimal type for the target language.
Cut-over failure. The switch to production is the highest-risk moment. A detailed cut-over plan with rollback and reconciliation is mandatory.

How to Get an Accurate Estimate

A reliable number comes from a code assessment, not a line count. A good assessment inventories programs and copybooks, identifies EXEC SQL / EXEC CICS / dynamic-call hotspots, gauges business-logic density, and maps the data access surface. The Mecanik COBOL migration service provides UK enterprise assessments and full-service migration; for mainframe estates on IBM z/OS, the legacy mainframe migration service covers the infrastructure decommission alongside the code.

Key Takeaways

A mid-size UK COBOL migration typically costs £200,000 to £800,000 over one to two years; mainframe decommissions run into the millions.
Complexity, undocumented business logic, and data access redesign drive cost far more than line count.
Target language and migration approach both move the budget in predictable ways.
Overruns come from underestimating discovery, testing, and cut-over; a proper code assessment is the only reliable basis for a quote.

Frequently Asked Questions (FAQ)

How much does a COBOL migration cost in the UK?
A small system typically costs £80,000 to £200,000, a mid-size system £200,000 to £800,000, and large systems £500,000 upward. Full mainframe decommission programmes run from £1,000,000 into the tens of millions. Complexity, not line count, sets where you land in the range.

How long does a COBOL migration take?
Small, well-documented systems take three to nine months. Mid-size enterprise systems run twelve to twenty-four months. Large mainframe programmes take three to five years or more for full decommission.

Why do COBOL migration costs vary so much?
Because complexity varies enormously. Undocumented business logic, embedded SQL and CICS, data format conversion, the target language, and the migration approach all move the cost. Two systems of the same line count can differ by an order of magnitude.

Does automated conversion reduce the cost?
It reduces mechanical translation effort, but no tool produces a finished system. You still budget for the data access layer, decimal-precision decisions, testing, and cut-over that the tooling flags for manual work.

What is the biggest cause of COBOL migration overruns?
Underestimating scope, especially undocumented business logic and the data access redesign. Building a regression test suite for output parity before migration begins is the single most effective way to control that risk.

WordPress Hacked: Malware Removal and Recovery Guide

Mecanik1337 — Sat, 03 Oct 2026 18:00:00 +0000

If your WordPress site was hacked and is now showing pharmaceutical spam, redirecting visitors to somewhere unpleasant, or has been flagged by Google as deceptive, start here rather than with a plugin. The instinct is to install a security scanner and click clean. That removes the visible symptom and leaves the way in, which is why so many sites get reinfected within days and their owners conclude that WordPress is simply insecure.

It is not. Almost every compromise arrives through an out-of-date plugin, and almost every failed cleanup happens because someone removed the malware without removing the access.

First hour: Take the site offline or into maintenance mode. Change the hosting control panel password, the database password, all administrator passwords and the FTP or SSH credentials. Do not restore a backup yet, and do not delete anything yet. You need the current state to work out how they got in, and a restore destroys that evidence while very likely reinstating the same vulnerability.

What to Do in the First Hour

Order matters here, and the common mistakes are all impatience.

Take the site down. A maintenance page or a temporary block at the hosting or CDN level protects visitors and stops the site distributing malware while you work. If the site is serving malicious redirects, every hour it stays up compounds the reputational damage.

Rotate every credential, not just the WordPress admin password. That means hosting panel, database user, FTP and SSH keys, and any API keys stored in the site's configuration. Attackers routinely create a second administrator account or leave a key behind, so changing one password achieves nothing.

Preserve the evidence before changing anything. Take a full copy of the files and database as they are now, and download the server access logs covering at least the last thirty days. Those logs are how you find the entry point, and many hosts rotate them within days.

Then, and only then, work out what happened.

How Your WordPress Site Got Hacked: Finding the Entry Point

Cleaning without diagnosis is why reinfection is so common. Four checks find the cause in most cases.

Check plugin and theme versions against known vulnerabilities. Out-of-date plugins are far and away the leading cause. Note every plugin, its version, and whether a security release exists that you have not applied. Pay particular attention to anything with an expired licence, because premium plugins stop receiving updates when the licence lapses while continuing to appear installed and active.

Read the access logs around the first sign of trouble. You are looking for POST requests to unusual paths, requests to files that should not exist, and a burst of activity from one address shortly before the defacement. This is usually where the answer is.

Look for files that do not belong. Recently modified PHP files in the uploads directory are a strong signal, because nothing should ever execute there. So are files with names designed to look plausible, and modifications to wp-config.php or .htaccess.

Check for added administrator accounts and scheduled tasks. Attackers commonly create a user to return through, and register a scheduled task that reinstalls the payload after you clean it. A site that keeps reinfecting on a regular cycle almost always has a scheduled task nobody looked for.

Why "Just Restore a Backup" Usually Fails

It is the first suggestion everyone receives and it is right about a third of the time.

Restoring works when you know the compromise date, have a backup from before it, and have identified and fixed the vulnerability. Without all three it fails predictably. Restore a backup from last week and you may be restoring a site that was already compromised two weeks ago and merely quiet. Restore without patching the vulnerable plugin and you have rebuilt the door you were locked out of.

There is also the problem of what a restore costs you. On a store or a membership site, rolling back means losing every order, registration and comment since the backup. That is often unacceptable, which pushes you towards cleaning the live site rather than replacing it.

The reliable approach is a rebuild rather than a restore. Install WordPress core fresh, install clean copies of every plugin and theme from their official sources rather than from the compromised site, and carry across only the uploads directory and the database — both inspected first. That guarantees the executable code is clean, which file-by-file cleaning never quite does.

Cleaning the Database

The database is where incomplete cleanups leave things behind, because scanners concentrate on files.

Injected content usually appears in post content as hidden links or iframes, in the options table where redirect scripts get stored, and in user metadata. Search for script tags, base64-encoded blocks and unfamiliar domains across the content and options tables.

Check the users table by hand. Look at every account with administrator privileges and confirm you recognise each one, then check registration dates against your own records.

Look at scheduled tasks, which in WordPress live in the options table. An entry pointing at a function you do not recognise is how a site reinfects itself on schedule long after the files were cleaned.

Take particular care with anything encoded. Attackers obfuscate payloads specifically so a search for obvious strings misses them, so decode anything suspicious rather than assuming it is a legitimate plugin doing something clever.

Getting Unflagged and Recovering Rankings

Cleaning the site is not the end, because the warnings persist until you ask for them to be reviewed.

If Google has flagged the site, the security issues report in Search Console tells you what was detected and lets you request a review once you have fixed it. Only request the review after the site is genuinely clean, because a failed review lengthens the process.

Check whether the domain has landed on blocklists used by browsers and email providers. Being clean is not enough on its own; each maintains its own list and its own removal process.

Then look at the damage. Search visibility usually recovers once warnings are lifted, but a site that spent weeks serving spam pages may have had those pages indexed. Check for indexed URLs that were never yours, remove them, and confirm the clean versions are being crawled. Our website security audit guide covers the verification steps in more detail.

What Professional Recovery Costs

Prices reflect typical UK rates and vary with how long the compromise went unnoticed.

A straightforward cleanup on a small site caught quickly, with a known cause, generally runs £400 to £1,200 and takes a day or two. This is the common case when someone notices within a week.

A full incident response — log analysis to establish entry point and timeline, clean rebuild, database inspection, credential rotation, hardening and blocklist removal — typically runs £1,500 to £5,000. This is what a store or a site holding customer data should expect, because you also need to establish whether data was accessed.

Sites compromised for months, or hosting several sites on the same account, cost more, because cross-contamination between sites on shared hosting is common and each one must be checked.

If personal data may have been accessed, there are obligations beyond the technical cleanup. UK GDPR requires notifying the ICO within 72 hours of becoming aware of a qualifying breach, and that clock starts at awareness, not at cleanup. Take advice early rather than after you have finished tidying. Our guide to GDPR technical compliance covers the engineering side of that.

Making Sure It Does Not Happen Again

Recovery without hardening just resets the clock.

Update discipline is the whole game. The overwhelming majority of compromises exploit a vulnerability with a patch already available, so the fix is a routine that applies security releases promptly and a policy of removing anything unmaintained. Premium plugins with lapsed licences should be renewed or replaced, never left in place.

Reduce what can execute. Nothing in the uploads directory should ever run as PHP, file editing from the admin interface should be disabled, and administrator accounts should be few and individually named.

Add multi-factor authentication on every administrator account and rate-limit the login endpoint. Most credential attacks are automated and stop being viable the moment a second factor exists.

Finally, back up properly and test it. A backup you have never restored is a hypothesis. Keep several generations, because the newest one may already contain the compromise. Our WordPress security hardening checklist sets out the full configuration, and our WordPress performance audit guide covers the plugin discipline that reduces the attack surface as a side effect.

Get It Cleaned Properly

Mecanik provides WordPress security audit and incident recovery work: establishing how the compromise happened, rebuilding cleanly rather than patching over it, inspecting the database, and hardening the site so the same route closes behind you.

We work from the server logs rather than from a scanner's output, because a scanner tells you what it recognises and the logs tell you what actually happened. Where the site handles customer data we will also tell you plainly whether you appear to have a notifiable breach, rather than leaving you to discover that later. Ongoing maintenance is available through our WordPress development service, which is generally cheaper than a second incident.

If your site is compromised right now, take it offline, rotate the credentials, keep the logs, and get in touch.

Frequently Asked Questions

What should I do first if my WordPress site is hacked?
Take the site offline, rotate every credential including hosting, database, FTP and all administrator accounts, and preserve a copy of the current files, database and server logs. Do not restore a backup or delete files yet, because that destroys the evidence needed to find the entry point.

Why does my WordPress site keep getting reinfected?
Almost always because the cleanup removed the malware but not the access. Look for administrator accounts you do not recognise, backdoors in the uploads directory, and scheduled tasks in the options table that reinstall the payload. Reinfection on a regular cycle usually indicates a scheduled task.

Can I just restore a backup to fix a hacked site?
Only if you know when the compromise happened, have a backup from before it, and have fixed the underlying vulnerability. Without all three you risk restoring an already-compromised site or reopening the same hole. A clean rebuild with fresh core, plugins and themes is more reliable.

How much does WordPress malware removal cost?
A straightforward cleanup on a small site caught early typically costs £400 to £1,200. A full incident response with log analysis, clean rebuild, database inspection and hardening generally runs £1,500 to £5,000, and long-running or multi-site compromises cost more.

How do I get my site unflagged by Google?
Clean the site fully, then request a review through the security issues report in Search Console. Only request it once the site is genuinely clean, since a failed review lengthens the process, and check separately for browser and email blocklists which each have their own removal procedure.

WooCommerce Performance: Why Your Store Is Slow

Mecanik1337 — Sat, 03 Oct 2026 06:00:00 +0000

Almost every WooCommerce performance investigation starts the same way. The store owner has already moved to a faster host, installed a caching plugin, and bought an image optimiser, and the site is still slow. They conclude that WooCommerce is simply heavy and give up.

WooCommerce is heavier than a brochure site, which is unavoidable when every page can carry a cart. But a store that takes six seconds to load is not suffering from that overhead. It is suffering from something specific, and in my experience it is nearly always one of four things.

The short version: Shops are slow because cart and checkout pages cannot be page-cached, because the options table has grown enormous with autoloaded junk, because product queries scan an unindexed metadata table, and because thirty plugins each add their own scripts to every page. Hosting is the last thing to change, not the first.

Why a Store Is Different From a Blog

Understanding one distinction explains most WooCommerce performance behaviour.

A blog post is the same for every visitor, so it can be generated once and served from cache to everyone. That is why brochure sites are fast almost regardless of how they are built. A store cannot do that on every page, because the cart is personal. The moment a visitor adds an item, the page has to reflect their state rather than a shared copy.

The consequence is that cart, checkout and account pages bypass page caching entirely and execute PHP and database queries on every request. Those are also the pages where slowness costs you money directly. A slow category page loses browsers; a slow checkout loses buyers.

So the useful question is never "is my site fast?" It is "how fast is my site for a logged-in visitor with something in their cart?" Test that state specifically, because it is the one your revenue depends on and the one every synthetic speed test misses.

The Four Things That Are Actually Wrong

An overloaded options table. WordPress loads a set of options on every single request, and plugins add to it freely. Uninstalled plugins routinely leave their rows behind. On older stores this table grows to tens of megabytes of autoloaded data being read on every page view including the checkout. It is invisible, it is cumulative, and it is one of the highest-return fixes available. Check the total size of autoloaded options first; if it is measured in megabytes rather than kilobytes, you have found real time.

Product queries against unindexed metadata. WooCommerce historically stored product attributes, prices and stock in a generic metadata table shared with everything else. Filtering or sorting a large catalogue means joining that table repeatedly. With a few hundred products nobody notices. With tens of thousands, category and filter pages slow to a crawl. Newer WooCommerce versions moved order data to dedicated tables specifically to relieve this pressure, and enabling that storage on a store with a long order history is usually worth doing on its own.

Plugins and External Calls

Plugin sprawl on the critical path. The problem is rarely the count itself; it is that most plugins enqueue their CSS and JavaScript on every page rather than only where needed. A booking plugin used on one page loads its assets on your checkout. The fix is unglamorous: audit what each plugin loads, dequeue assets outside their own pages, and remove anything whose function you cannot name.

Uncached third-party calls. Live shipping rates, tax lookups, currency conversion and stock checks against an external system all place a network request inside the page load. When that provider is slow, your checkout is slow, and when it fails your checkout fails. Every external call in a request path needs a timeout, a cache and a fallback. Our guide to third-party API integration covers how that should be built.

What Actually Helps, In Order

Work through these in sequence, because each one changes what the next measurement tells you.

Object caching, not just page caching. Page caching serves whole HTML pages and cannot help cart or checkout. A persistent object cache stores the results of database queries in memory and speeds up exactly the pages page caching cannot touch. For a store this is usually the single largest improvement available, and it is the step most often skipped because the caching plugin already installed gave the impression the job was done.

Database maintenance. Clear expired transients, remove orphaned metadata from deleted products and orders, and trim post revisions. On a store that has been trading for years this routinely removes a large fraction of the database. Schedule it rather than doing it once.

Then hosting. Once caching and the database are in order, hosting genuinely matters: PHP version, available memory, whether the database is on the same machine, and whether you are on shared hosting competing with other tenants. But moving host before fixing the above just relocates the problem to a more expensive address.

Assets last. Image formats, lazy loading and script deferral are worth doing and they are what most guides lead with. They improve the loading experience of pages that were already being served reasonably quickly. They do very little for a checkout that spends four seconds in PHP before sending a byte.

Measuring WooCommerce Performance Properly

Synthetic scores mislead store owners more than any other group, so measure deliberately.

Test the logged-in, cart-populated state. Most tools test an anonymous visitor hitting the homepage, which is the fastest possible path through your site and tells you almost nothing about checkout.

Separate server time from front-end time. If the server takes three seconds to produce the HTML, no amount of image optimisation will save the page. Time to first byte tells you which half of the problem you have, and therefore which of the fixes above applies.

Use field data rather than lab data where you can. Real visitors on real connections and real phones produce a different picture from a test run in a data centre, and Core Web Vitals are assessed on the former. Our WordPress performance audit guide covers how to read those metrics properly, and Core Web Vitals in 2026 explains what the thresholds actually require.

Finally, watch the database directly during a slow request. A query log showing the same query executed two hundred times on one page load identifies the culprit immediately, and that pattern is extremely common in stores running several plugins that each ask for product data independently.

What This Work Costs

Prices below reflect typical UK agency rates for a store of moderate size.

A performance audit that identifies the specific causes, with a prioritised fix list and before-and-after measurements, generally runs £900 to £2,500. That is a diagnostic engagement and it is worth buying separately, because it tells you whether the remaining work is a week or a month.

Implementing the common fixes — object caching, database cleanup, plugin asset auditing, external call caching — usually runs £2,000 to £6,000 depending on how much has accumulated.

Deeper work costs more because it is genuinely development. Migrating a large catalogue to indexed storage, rebuilding a filter system that scans metadata, or replacing a slow plugin with a targeted custom implementation typically falls between £6,000 and £20,000.

The figure that matters more than any of these is what slowness costs you. Checkout abandonment rises measurably with load time, so a store turning over meaningful revenue can usually justify the audit on the checkout page alone.

Fix the Store, Not the Score

Mecanik does WooCommerce performance work as part of our WordPress development service, and we start by measuring the logged-in checkout path rather than the homepage, because that is where stores actually lose money.

We look at autoloaded options, order storage, query patterns and external calls before recommending a host change, and we give you the measurements both before and after so the improvement is verifiable rather than asserted. If your store is slow because it has outgrown the platform rather than because it is misconfigured, we will tell you that too — our comparison of Shopify and custom ecommerce covers where that line sits.

Send us the URL and roughly how many products and orders the store holds, and we will tell you which of the four causes above you are most likely facing.

Frequently Asked Questions

Why is my WooCommerce site slow even with a caching plugin?
Page caching cannot be applied to cart, checkout and account pages, because those must reflect each visitor's own state. Those pages execute PHP and database queries on every request, so speeding them up requires object caching and database work rather than page caching.

Does moving to better hosting fix WooCommerce performance?
Only partly, and it should not be the first step. If the options table is bloated, queries are unindexed and plugins load assets everywhere, better hosting makes the same problems slightly faster at higher cost. Fix caching and the database first, then reassess hosting.

How many plugins are too many for WooCommerce?
The count matters less than what each one loads. Twenty well-behaved plugins that only enqueue assets on their own pages cause less harm than eight that load scripts site-wide. Audit what each adds to the checkout, and remove anything whose purpose nobody can state.

What does WooCommerce speed optimisation cost?
A diagnostic audit with a prioritised fix list typically costs £900 to £2,500. Implementing common fixes such as object caching, database cleanup and asset auditing usually runs £2,000 to £6,000, while catalogue or filter rework can reach £6,000 to £20,000.

How should I test WooCommerce performance properly?
Test as a logged-in visitor with items in the cart, not an anonymous homepage visit. Separate server response time from front-end rendering to see which half is slow, and use field data from real visitors rather than relying only on lab scores.

Penetration Testing Cost: 2026 Enterprise Budgeting Guide

Mecanik1337 — Fri, 02 Oct 2026 18:00:00 +0000

Calculating the cost of penetration testing in the UK is a vital compliance task for enterprises planning cyber security audits in 2026. With business transactions shifting online, maintaining strict application security is critical to protect sensitive client databases and avoid expensive regulatory penalties. Commissioning an annual penetration test has shifted from a general recommendation to a standard requirement under local frameworks. This guide breaks down the pricing models, scope definitions, and compliance standards used to calculate penetration testing budgets.

Compliance Risk Warning: Relying purely on automated vulnerability scanners does not constitute a penetration test. Under standard industry frameworks, automated tools fail to identify complex logic bugs, leaving your systems vulnerable to manual breaches.

Key Takeaways:

Costs vary based on IP count, active user roles, and network complexity.

Small-scale web application pen tests range from £3,500 to £6,500, while complex enterprise networks start at £8,000.

Working with CREST-accredited agencies is essential to pass compliance frameworks like ISO 27001 or PCI-DSS.

Retaining a detailed vulnerability report simplifies structural remediation, saving engineering hours post-audit.

Variables That Dictate Penetration Testing Cost

A professional security audit requires manual validation by experienced ethical hackers. According to guidelines from the National Cyber Security Centre (NCSC), scoping security tests accurately is the first step to prevent budget overruns. Several parameters directly impact the scope of work and the final quote. Therefore, you must define the target surfaces cleanly to avoid budget creep.

1. Scope and Target Count

The number of servers, external IP addresses, internal domains, and active APIs dictates the test duration. Additionally, a web application with multiple user access levels requires testing each authorisation path to identify privilege escalation risks.

2. Testing Methodology: Black vs. White Box

The amount of information provided to the security engineers determines the testing path and, ultimately, the testing style.

Black-Box Testing: Engineers receive only the target URL or IP. This method simulates an external attack, requiring more hours to gather intelligence and map endpoints.
White-Box Testing: Developers provide source code access, network diagrams, and database configurations. This allows for deep review but requires close collaboration.

3. Compliance and Industry Requirements

UK businesses bidding for public sector contracts or working in fintech must meet specific security baselines (such as Cyber Essentials Plus or PCI-DSS). To satisfy these audit criteria, the testing agency must run specialised tests, and this additional compliance layer increases testing hours and the final fee.

Average Penetration Testing Costs in the UK for 2026

To help your compliance team budget, the following table details the average cost metrics for security audits in the UK:

Testing Target	Average Cost Range (GBP)	Recommended Testing Frequency	Compliance Standards Met
Simple Web App / API	£3,500 - £6,500	Annual / Post-Update	GDPR / OWASP Top 10
Enterprise Network (Internal & External)	£8,000 - £15,000+	Annual	ISO 27001 / PCI-DSS
Active Mobile Application (iOS & Android)	£5,000 - £10,000	Annual	OWASP MASVS
Cloud Infrastructure (AWS/Cloudflare)	£6,000 - £12,000	Annual / Major Change	CIS Benchmarks

These estimates assume hiring a certified agency that provides comprehensive liability insurance and senior, accredited testers.

How a Pen-Test Quote Is Built: A Worked Example

Most reputable UK consultancies price on a day-rate basis. The quote is simply the estimated number of testing days multiplied by the consultant day rate, plus reporting and a retest. This makes the arithmetic easy to interrogate once you know the inputs. For CREST-registered testers, day rates typically sit between £1,000 and £1,500 per day (illustrative for 2026); highly specialised work — bespoke thick-client, embedded, or hardware testing — commands more.

Consider a realistic scenario: a mid-sized SaaS business commissioning its annual assessment. The in-scope assets are a customer-facing web application with three user roles, the REST API behind it, and a small external network perimeter. A blended senior rate of £1,200 per day applies across the engagement.

Component	Scope detail	Estimated effort (days)	Subtotal at £1,200/day
Web application (authenticated)	3 user roles, ~25 dynamic pages	5.0	£6,000
REST API	~40 endpoints	2.5	£3,000
External network	12 live IP addresses	1.5	£1,800
Reporting & QA	Findings write-up, executive summary, peer review	1.5	£1,800
Remediation retest	Verify critical and high-severity fixes	1.0	£1,200
Total	—	11.5 days	£13,800

The headline figure of roughly £13,800 is therefore not a mysterious lump sum. It is 11.5 days of effort at a £1,200 blended rate. The day counts themselves come from a scoping questionnaire: the tester estimates hours per authorisation path, per endpoint cluster, and per network segment, then rounds to sensible half-days. Change any input and the price moves predictably. Add a native mobile application and you add roughly 4 to 6 days (£4,800–£7,200). Insist on a fully black-box engagement and reconnaissance alone can add a day or two, because the team must map from scratch what a white-box brief would have handed over.

Most agencies present this as a fixed-price quote rather than an open day rate, having converted their day estimate into a single figure. The practical difference matters at contract time: a fixed price protects you if the work runs long, but only against the scope you agreed, so anything discovered outside the original boundary becomes a change request. Always confirm what the quote assumes — the number of days baked in, whether one retest is included, and how out-of-scope findings are handled — before you sign. A supplier who cannot break their fixed price back down into days and rates is a supplier worth questioning.

What Makes Up the Headline Price: A Line-Item Breakdown

Even within a single engagement, the fee covers far more than hands-on-keyboard exploitation. Understanding how the effort divides helps you compare quotes like for like and spot a supplier who has under-scoped the unglamorous stages.

Stage	What it covers	Typical share of effort
Scoping & pre-engagement	Questionnaire, rules of engagement, written authorisation	5–10%
Reconnaissance & mapping	Enumerating the attack surface, cataloguing endpoints	10–15%
Active testing & exploitation	Manual testing, chaining findings, privilege escalation	45–55%
Reporting & QA review	Write-up, severity ratings, senior peer review	20–25%
Remediation retest	Re-testing issues your team has patched	5–10%

The reporting stage surprises many first-time buyers. A test that finds serious problems but documents them poorly is close to worthless: your engineers cannot reproduce or prioritise what they cannot understand. When you analyse two quotes and one is conspicuously cheaper, check whether it has quietly compressed reporting and retesting — that is usually where corners get cut.

Ongoing and Hidden Costs to Budget For

The invoice from the testing agency is rarely the whole story. A realistic annual security budget should account for these recurring or easily overlooked items:

Remediation engineering time. Fixing what the test finds is frequently the single largest cost, and it lands on your own team rather than the supplier's invoice. A report with a dozen medium and high findings can absorb several developer-weeks.
Annual re-testing. Frameworks such as ISO 27001 and PCI-DSS expect a fresh assessment at least yearly, plus targeted testing after any major change.
Retest and validation fees. Most engagements include one retest window; verifying fixes after that window has closed is usually billed separately.
Interim scanning and tooling. Many organisations run authenticated vulnerability scanning between annual tests, which carries its own licence cost.
Internal staff time. Scoping calls, environment preparation, and provisioning test accounts all consume hours that rarely appear in any quote.

As an annual rule of thumb, plan for total security-testing spend of roughly 1.5 to 2 times the headline test fee once remediation labour, retests, and interim scanning are included (illustrative). In our worked example, the £13,800 engagement realistically implies a £20,000–£28,000 all-in annual figure for that programme of work.

What Moves the Price Up or Down

Because the model is days multiplied by a rate, every price lever ultimately changes the day count. The factors below push a quote in one direction or the other:

Pushes it up: a fully black-box brief, many user roles or authorisation boundaries, compliance overlays such as PCI-DSS or CBEST that mandate specific methodologies and evidence, out-of-hours testing to protect production, and any physical or social-engineering component.
Pulls it down: a tightly defined and well-documented scope, white-box or grey-box access, consolidating several assets into one booking, a stable code freeze during the test window, and a standing retainer relationship that removes repeated scoping overhead.

Best Practices to Control Testing Expenses

Protecting your budget from inflation requires preparing your systems before the audit begins. To keep costs under control, follow these optimisation guidelines:

Clean up Active Codebases: Resolve obvious OWASP vulnerability points using automated scanners before the engineers start testing.
Establish Clear Scopes: Exclude non-critical staging subdomains or legacy static servers from the target list to limit testing hours.
Verify Third-Party Approvals: If your systems are hosted on managed servers, ensure you secure authorisation from the host to prevent testing blocks.
Link remediations to SLAs: Ensure your engineering team is scheduled to patch identified vulnerabilities immediately upon receiving the draft report.

Partner with a Vetted UK Security Consultancy

Understanding the elements that shape your budget ensures your compliance audits stay on schedule. Mecanik provides professional penetration testing services and comprehensive security testing through the website security audit page. We specialise in web application security, server hardening, and API compliance audits. Contact us today to schedule your scoping session.

Frequently Asked Questions

What is the average penetration testing cost uk?
The average cost of a penetration test in the UK starts at £3,500 for a simple web application or API and can exceed £15,000 for complex enterprise networks. The final pricing depends on the number of IP addresses, active endpoints, user roles, and compliance requirements.

Why do I need a manual penetration test instead of a scanner?
Automated scanners only identify known signature patterns. Conversely, a manual penetration test uses ethical hackers to identify complex logic flaws, chain minor issues into critical breaches, and verify access escalation bugs that scanners cannot spot.

How often should a UK business conduct a pen test?
UK businesses should conduct a penetration test at least once a year to maintain compliance standards like ISO 27001. Additionally, you should commission a pen test after launching major feature updates, changing database structures, or shifting cloud hosts.

What is the role of CREST accreditation in pen testing?
CREST accreditation verifies that the security agency and its engineers follow strict technical, ethical, and legal guidelines. Hiring a CREST-approved firm is often a requirement to satisfy compliance audits and validate your security posture to enterprise clients.

What happens if the pen test identifies critical vulnerabilities?
A professional test report categorises vulnerabilities by severity (Critical, High, Medium, Low). Your development team should patch critical and high risks immediately, and the testing agency should run a validation test to confirm the patches are secure.

Core Web Vitals in 2026: How to Actually Pass

Mecanik1337 — Fri, 02 Oct 2026 06:00:00 +0000

Core Web Vitals are Google's measurable signals for real-world page experience, and they feed into ranking. Passing them is not about chasing a green score for its own sake; it is about a site that loads fast, responds instantly, and does not jump around while people use it. This guide explains the three metrics as they stand in 2026 and, more importantly, the fixes that actually move each one.

TL;DR

The three Core Web Vitals are LCP (loading), INP (responsiveness), and CLS (visual stability). INP replaced FID as a Core Web Vital in 2024
"Good" thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1, measured at the 75th percentile of real visits
The highest-impact fixes are optimising the largest image or text block, reducing and breaking up JavaScript, and reserving space for images, ads, and embeds
Use field data (real users), not just lab tests, because Google ranks on real-world performance

The Three Core Web Vitals (2026)

Largest Contentful Paint (LCP): Loading

LCP measures how long it takes for the largest visible element (usually a hero image, banner, or large text block) to render. Good: under 2.5 seconds.

Interaction to Next Paint (INP): Responsiveness

INP measures how quickly the page responds to user interactions across the whole visit, replacing the older First Input Delay (FID) metric in 2024. It captures the delay between a tap or click and the next visual update. Good: under 200 milliseconds.

Cumulative Layout Shift (CLS): Visual Stability

CLS measures how much the page unexpectedly shifts while loading (the frustrating jump when a late image or ad pushes content down). Good: under 0.1.

Google evaluates these at the 75th percentile of real visits, so you need most of your users, not just the fastest, to have a good experience.

Fixing LCP

Optimise the LCP element. Identify it (most tools name it) and make it load fast: compress and correctly size the image, serve modern formats (WebP/AVIF), and avoid lazy-loading the hero image.
Serve responsive images with a proper srcset so devices download an appropriately sized file rather than a huge one. (See the guide to dealing with responsive images.)
Speed up the server response (TTFB) with caching and a CDN so the document arrives quickly.
Preload critical resources (the LCP image, key fonts) and eliminate render-blocking CSS and JavaScript where possible.
Use a fast image pipeline. Serving images through an optimised service like Cloudflare image transformations resizes and compresses on the fly.

Fixing INP

Reduce JavaScript execution. Heavy scripts block the main thread and delay responses. Ship less JavaScript and remove unused code.
Break up long tasks. Split long-running work so the browser can respond to input between chunks.
Defer non-critical work until after interaction, and avoid large, synchronous handlers.
Audit third-party scripts. Tag managers, chat widgets, and analytics are common INP culprits; load them efficiently or remove what you do not need.

Fixing CLS

Always set width and height (or CSS aspect-ratio) on images and video so the browser reserves space.
Reserve space for ads, embeds, and iframes so they do not push content when they load.
Avoid inserting content above existing content after load.
Preload fonts and use font-display sensibly to reduce layout shift from late-loading fonts.

Measure the Right Way

Field data over lab data. Google ranks on real-user (field) data such as the Chrome User Experience Report, not just a single lab run. A perfect lab score with poor field data will not pass.
Watch the 75th percentile. Improving your median is not enough; the slower quarter of visits is what fails you.
Test on real devices and connections, especially mid-range mobile, not just a fast desktop.

Key Takeaways

The three Core Web Vitals in 2026 are LCP, INP (which replaced FID), and CLS.
Aim for LCP under 2.5s, INP under 200ms, and CLS under 0.1 at the 75th percentile of real visits.
The biggest wins: optimise the LCP element and images, cut and split JavaScript for INP, and reserve space to stop layout shift for CLS.
Judge success on field data, not just a lab score.

Get a Professional Assessment

Core Web Vitals are one part of technical SEO. A technical SEO audit covers Core Web Vitals alongside crawl budget, indexation, site architecture, JavaScript rendering, and structured data, with a prioritised action plan based on real ranking impact. If speed is your main concern, the guide to speeding up your website with Cloudflare goes deeper on performance.

Frequently Asked Questions (FAQ)

What are the three Core Web Vitals in 2026?
Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. INP replaced First Input Delay (FID) as a Core Web Vital in 2024.

What are good Core Web Vitals scores?
LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of real user visits. You need most visitors, not just the fastest, to hit these.

Do Core Web Vitals affect Google rankings?
Yes. They are part of Google's page experience signals. They are not the only or the strongest ranking factor, but for competitive queries a good page experience is a meaningful advantage, and a bad one holds you back.

Why does my site pass in the lab but fail in Search Console?
Because Google uses field data from real users, not a single lab test. Real devices, connections, and the 75th percentile expose problems a fast test machine hides. Optimise for real-world conditions.

What is the fastest way to improve Core Web Vitals?
Usually optimising the LCP element (compress and size the largest image, avoid lazy-loading it) and reducing JavaScript. For CLS, set dimensions on images and reserve space for ads and embeds.