DEV Community: n k

HTTP/2 and HTTP/3 — What the Protocol Upgrades Actually Do for Web Performance

n k — Tue, 22 Sep 2026 06:04:20 +0000

HTTP/1.1, the version of the web protocol that powered the internet for over two decades, has a fundamental performance limitation: each request-response pair on a connection blocks subsequent requests until it completes. Even with multiple parallel connections, this sequential processing creates head-of-line blocking where one slow response delays others in the same queue. HTTP/2 and HTTP/3 address this in different ways, with real performance implications that website owners and developers benefit from understanding.

HTTP/2's core improvement is multiplexing: multiple request-response pairs can be in flight simultaneously on a single connection, with responses returned in any order as they become available rather than the order they were requested. A page that requires twenty resources to load no longer needs to request them in sequential batches constrained by connection count — all twenty can be requested simultaneously and responses arrive as they're ready.

HTTP/2 also introduced header compression (HPACK), which reduces the overhead of HTTP headers that are repeated across many requests to the same server. For pages making many requests to the same origin — common with single-page applications — this compression produces meaningful bandwidth reduction.

The requirement for HTTP/2 is HTTPS — HTTP/2 is only available over encrypted connections in all practical implementations. The SSL configuration on shared hosting that enables HTTPS also enables HTTP/2 access, which is one of the performance reasons that HTTPS has become the unambiguous recommendation even for sites that don't handle sensitive data.

HTTP/3 addresses a different limitation: the TCP-based transport that HTTP/1.1 and HTTP/2 use has its own head-of-line blocking problem at the transport layer. Packet loss on a TCP connection stalls all streams using that connection while retransmission occurs. HTTP/3 uses QUIC, a UDP-based protocol that handles individual streams independently — packet loss in one stream doesn't stall others. For mobile connections and high-latency networks where packet loss is more frequent, HTTP/3 produces meaningful improvements over HTTP/2.

Server and hosting infrastructure support for HTTP/3 is less universal than HTTP/2 support but growing. For sites with mobile-heavy traffic or global audiences on variable-quality connections, HTTP/3 support is a meaningful performance consideration. For sites with primarily desktop and high-quality connection audiences, HTTP/2 provides most of the available protocol-level performance improvement.

The practical takeaway: checking whether your web hosting environment supports HTTP/2 (and ideally HTTP/3) is worth doing, because these protocol improvements produce performance gains without any code changes on your part — the improvement happens at the protocol level once the server supports it and HTTPS is properly configured.

PHP-FPM Configuration — What Web Developers Should Know for Performance

n k — Mon, 21 Sep 2026 06:08:58 +0000

PHP-FPM (FastCGI Process Manager) is the PHP execution model that most modern web applications use, and its configuration significantly affects both the performance and the resource usage of PHP-based websites. Understanding how it works helps developers and system administrators make better decisions about server sizing, identify the cause of performance problems, and configure it appropriately for specific workloads.

The basic model: PHP-FPM maintains a pool of PHP worker processes that are ready to handle requests. When a web server receives a request that requires PHP, it passes the request to PHP-FPM, which assigns it to an available worker. If no worker is available and the pool is at its configured maximum, the request waits in a queue until a worker becomes available. This is the mechanism through which PHP-FPM creates the specific failure mode of slow responses under load — not from server resource exhaustion but from request queuing behind a pool that's too small.

The critical configuration parameters:

pm.max_children: the maximum number of PHP worker processes. This is the fundamental capacity limit — no more than this many PHP requests can execute simultaneously. Setting this too low causes queuing under load; setting it too high with insufficient RAM causes memory exhaustion.

pm.start_servers, min_spare_servers, max_spare_servers: how many workers to maintain when idle. For steady traffic, more pre-forked workers reduces latency for incoming requests; for variable or bursty traffic, too many idle workers wastes RAM.

pm.max_requests: how many requests each worker handles before being recycled. Setting this prevents PHP memory leaks from accumulating over many requests, which is a specific cause of memory growth that looks like a leak but is actually accumulated garbage collection overhead.

The PHP web server configuration that most users experience is managed by their hosting provider; understanding what they're managing helps diagnose symptoms. A WordPress site that gets slow specifically under concurrent load, rather than slow always, is often hitting PHP-FPM worker exhaustion — the pool is too small for the traffic. The specific error — 504 Gateway Timeout — occurs when a request waits longer than the configured timeout for an available worker.

Memory limits interact with PHP-FPM sizing in a specific way: if you have 2GB of RAM allocated for PHP-FPM, and each PHP process uses 50MB on average, you can run a maximum of about 40 workers before running out of memory. Setting pm.max_children higher than the memory allows causes OOM errors that kill workers. Understanding this relationship is what connects server infrastructure sizing to application performance planning.

The monitoring signal that PHP-FPM is the bottleneck: 504 errors under load that don't appear under light load, combined with the PHP-FPM pool log showing requests queuing behind a full worker pool. The fix is either upgrading to more resources (more RAM to allow more workers) or optimising PHP application performance (faster PHP requests release workers sooner, increasing effective capacity).

The Linux Boot Process — Understanding What Happens Between Power-On and Login

n k — Fri, 18 Sep 2026 05:27:00 +0000

The Linux boot process is one of those topics that most administrators understand at a vague level — something happens, and then the system is ready — and need to understand specifically when things go wrong during boot, which is one of the more stressful failure scenarios because the system isn't accessible through normal means while it's failing to start.

The sequence of events from power-on to a running Linux system has several distinct stages, each responsible for specific initialisation tasks and each failing in specific, diagnosable ways.

The firmware stage (BIOS or UEFI) is the first, running before any operating system software is involved. The firmware checks hardware, locates the boot device, loads the initial bootloader code, and hands control to it. Failures at this stage — hardware detection failures, missing boot device — produce error messages from the firmware rather than from Linux, which distinguishes them from later boot failures.

The bootloader stage (almost universally GRUB on modern Linux systems) manages the selection of which operating system or kernel version to load, loads the kernel and initial ramdisk into memory, and passes control to the kernel. GRUB failures — a corrupted configuration file, a missing kernel file — produce a specific GRUB error or rescue shell, not a Linux kernel error. Understanding Linux boot process fundamentals at this level allows immediate identification of which stage is failing from the specific error presentation.

The kernel initialisation stage is where the Linux kernel takes control, initialises hardware, mounts the initial ramdisk (a minimal filesystem used during boot), and eventually mounts the real root filesystem. Kernel panics at this stage — typically from a missing driver required to access the root filesystem, or from a corrupted root filesystem — produce specific panic messages that identify the cause.

The init system stage (systemd on modern distributions) is where services start in the correct dependency order, filesystems are mounted, and the system reaches a usable state. Failures here are the most common boot problems in running systems, because this is where application-layer configuration errors manifest. A service that fails to start because of a configuration error, a filesystem mount that fails because of a corrupted filesystem entry, a network service that can't bind because of a conflicting port assignment — these are systemd and service management problems that require different diagnostic approaches from firmware or kernel failures.

The practical boot troubleshooting capability this understanding enables: looking at which error presentation you're getting immediately narrows the diagnosis to the relevant stage. A GRUB rescue prompt is a different problem from a systemd service failure is a different problem from a kernel panic, and each requires different tools and approaches. Systematic Linux troubleshooting built on this understanding produces faster resolution than trial-and-error recovery attempts.

Web Server Configuration Essentials — What Every Hosting Customer Should Understand

n k — Thu, 17 Sep 2026 06:03:32 +0000

Web servers — Apache and Nginx being the two most widely deployed — are the software layer that receives incoming requests for your website and decides how to handle them. Most shared hosting customers interact with their web server's configuration through a control panel interface without ever seeing the configuration files directly, and this abstraction works well for standard cases. Understanding what the web server is actually doing, however, is useful for diagnosing the specific class of problems that control panel interfaces don't expose clearly.

The most operationally significant web server configuration for most WordPress and PHP-based websites: the rules file (typically .htaccess for Apache) that determines how incoming request URLs are mapped to actual files, how requests are redirected, what headers are sent with responses, and various other request handling behaviours. Most WordPress permalink structures, most redirect configurations, and many security configurations live in this file. A corrupted or incorrectly configured .htaccess file is one of the most common causes of WordPress errors that appear as 500 Internal Server Error or 404 errors for URLs that should exist — the web server is returning these errors because the rules file is telling it to, not because the underlying content doesn't exist.

PHP configuration within the web server context — specifically the PHP settings that determine memory limits, execution time limits, and upload size limits — is the second most common source of confusing errors for website owners who haven't connected the symptoms to the cause. A media upload that fails without explanation may be hitting the upload size limit. A plugin that times out may be hitting the execution time limit. An out-of-memory error during a complex operation may be hitting the PHP memory limit. These are web server and PHP configuration variables, not code bugs, and fixing them requires configuration changes rather than debugging.

The hosting infrastructure that gives you appropriate access to these configuration variables — through a functional control panel or through direct configuration file access — determines whether you can resolve this class of problems yourself or need to wait for hosting support. Quality hosting environments expose these configuration options in ways that allow site owners or their developers to make necessary adjustments without escalating every configuration change.

Virtual host configuration — how the web server maps incoming requests for different domain names to different website files — is the configuration that determines which website is served for which domain, which is relevant for hosting environments that serve multiple domains from the same account. Reliable web hosting infrastructure that correctly configures virtual hosting is the baseline that makes multi-domain or subdomain hosting work correctly; misconfigured virtual hosting produces the confusing experience of visiting one domain and seeing content intended for a different one.

SSL termination configuration — where in the infrastructure the HTTPS connection is decrypted and how it's handled for the application — matters for performance and for correct header forwarding that some applications depend on. A web application that receives traffic through an SSL-terminating proxy but doesn't know it's behind a proxy may generate incorrect URLs or fail to correctly identify secure versus insecure requests. Properly configured hosting environments handle this transparently for standard applications; custom applications may need specific configuration to work correctly with the proxy architecture.

Environment Variables in Linux — What They Are and Why They Matter More Than Most Beginners Realise

n k — Wed, 16 Sep 2026 06:15:13 +0000

Environment variables are one of the Linux concepts that beginning developers and system administrators encounter early, learn a surface-level usage of, and then discover repeatedly in contexts where the surface-level understanding is insufficient. They're present in more of what you do in Linux than most people initially realise, and understanding them properly prevents a significant class of configuration errors that otherwise produce confusing, hard-to-diagnose failures.

The basic concept: environment variables are name-value pairs that are part of the environment in which a process runs, inherited from the parent process that created it, and available to the process itself and any processes it creates. They're used to configure application behaviour without modifying application code — a database URL, an API key, a mode flag, a path to a configuration file. The operating system also uses them for foundational configuration: the PATH variable that determines where the shell looks for executable commands, the HOME variable that stores the current user's home directory, the SHELL variable that identifies the current shell.

The reason environment variables cause more confusion than their simple concept suggests: they're not global. They're per-process, and they're inherited only in specific ways. A variable set in one terminal session doesn't exist in another terminal session. A variable exported in a shell script doesn't persist after the script exits. A variable set in one user's environment isn't visible to another user's processes. A variable set at the command line isn't necessarily visible to the system service running the application you're trying to configure. These scoping rules are consistent and logical, but they're frequently not understood by people who've learned "set an environment variable" without understanding "set it where?"

The specific scoping confusion that causes the most problems in practice: the difference between a variable set for the current session and a variable set persistently for a user. A variable set interactively in a terminal session disappears when the session ends. A variable set in the shell configuration files that are read at login or shell startup persists across sessions. The Linux environment configuration approach for persistent variables — which file to modify, when those changes take effect, and how to verify they're applied — is the practical knowledge that prevents repeated frustration with variables that "keep disappearing."

Application configuration through environment variables rather than configuration files has become increasingly standard, particularly for containerised applications and for applications designed to be deployed across different environments. The principle: code is deployed without environment-specific configuration embedded in it; the environment provides the configuration through variables at runtime. This makes the same application code deployable in development, staging, and production environments by changing the environment rather than the code. Understanding how to work with this configuration model is foundational for anyone working with modern application deployment.

Security implications of environment variables are worth understanding specifically: they're accessible to all processes running as the same user, they can appear in process listings in some configurations, and they persist in logs if applications log their startup environment. Secrets — passwords, API keys, cryptographic credentials — managed through environment variables need additional security considerations beyond just "put it in an environment variable." Learning Linux in production contexts covers these security considerations as part of operational practice rather than as an advanced topic to encounter later.

Database Performance on Shared Hosting — What Developers Need to Know

n k — Tue, 15 Sep 2026 05:54:58 +0000

Database performance is where many web applications that perform acceptably under development conditions fail under production load, and the relationship between database performance and hosting infrastructure is more direct than most developers account for when making hosting decisions.

The development environment is almost always deceptively fast for database operations. The database runs on the same machine as the application, network latency between them is effectively zero, the dataset is small, and there are no other queries competing for database resources simultaneously. None of these conditions apply in production at scale.

In production on shared hosting, the database is typically on the same physical server as the application but serving many other databases for many other accounts simultaneously. Query response times vary based on overall server load rather than just your application's specific query load. Memory allocated to the database buffer pool — the cache that keeps frequently accessed data in memory rather than requiring disk reads — is shared across all databases on the server and may be insufficient for your application's working set.

The most common database performance problem on shared hosting: queries that are fast in development become slow in production because they're doing full table scans that worked fine on a small development dataset but require reading millions of rows in production. The solution is indexing — creating indexes that allow the database to find rows matching query conditions efficiently rather than scanning the entire table — but identifying which queries need indexes requires production-scale data or realistic performance testing before production deployment. A well-configured hosting environment for web applications should provide access to slow query logs that identify which queries are consuming disproportionate time.

Connection pooling is the second database performance issue that shared hosting environments commonly expose. Database connections have overhead — establishing them takes time, and maintaining too many simultaneously consumes server resources. Applications that open a new database connection for every request rather than reusing existing connections from a pool can exhaust database connection limits on shared hosting in ways that don't appear in development. Understanding how your application framework manages database connections and how to configure connection pooling correctly is important before reaching production load.

For applications that have outgrown shared hosting database performance, dedicated database resources on a VPS or dedicated server provide isolation from other accounts' database activity and allow database configuration to be tuned for your specific application's query patterns. The transition from shared database infrastructure to dedicated is often the most impactful single performance improvement available to an application that's hitting shared hosting limits, because it addresses the root cause — resource contention — rather than the symptoms. Choosing hosting infrastructure with honest assessment of database requirements prevents the reactive infrastructure crisis that occurs when production load reveals what development testing didn't.

Linux for Junior Developers — The Skills That Make You More Effective From Day One

n k — Fri, 11 Sep 2026 07:23:08 +0000

Junior developers are often surprised by how much of professional software development involves Linux in practical, daily ways rather than just theoretically. The development environments that software runs in, the deployment targets that code gets pushed to, the build systems that compile and test code, the CI/CD pipelines that automate all of this — most of it is Linux infrastructure, and the developer who can navigate it confidently is more effective than one who treats it as someone else's problem.

The specific Linux skills that matter most for junior developers in daily work are narrower than full system administration competence — you don't need to manage production servers from day one — but more than surface familiarity with a few commands. The command line is the environment where most development workflows actually operate, and fluency in it changes how fast and how confidently you can work.

File system navigation and manipulation — moving efficiently between directories, finding files based on content or modification time, managing file permissions that affect whether scripts and executables can run — is daily developer work that goes faster and with fewer frustrating blocks for someone who's genuinely fluent than for someone who has to look up commands for basic operations. Linux command fluency developed through actual practice rather than tutorial exposure is what produces the fluency that changes the daily experience.

Process management — understanding what processes are running, how to identify a stuck process that's blocking something, how to manage background versus foreground execution — is relevant for developers who run local development servers, who execute test suites, and who run long-running processes as part of their workflow. The developer who freezes at an unexpected terminal state is producing unnecessary context-switching cost compared to one who can resolve it quickly and return to what they were doing.

Environment variables and shell configuration — how the development environment is configured, how tools find each other, how path variables and configuration files interact — is the context in which "it works on my machine" problems live. Understanding how the shell environment is constructed allows debugging of these problems rather than the resort to machine-specific instructions that aren't reproducible or maintainable.

Git operations from the command line is worth specifically mentioning because many junior developers learn Git through GUI clients that abstract away the command-line operations, and then encounter situations in professional work where the GUI abstraction either doesn't exist or doesn't expose the specific operation that's needed. Working with version control at the command level produces more resilient Git fluency than GUI-only experience.

Docker and container tooling — increasingly standard in professional development environments — operates primarily through a Linux command-line interface and assumes Linux conceptual foundations about processes, file systems, and networking. A junior developer who already has Linux fluency adapts to container workflows much more quickly than one who encounters Linux concepts for the first time through the container abstraction. Practical technical foundations built before encountering the tools that depend on them produce faster, more confident development of tool-specific capability than trying to learn both the tool and its foundations simultaneously.

Why Server Response Time Matters More Than Most Website Owners Realise

n k — Thu, 10 Sep 2026 07:21:44 +0000

Time to First Byte — TTFB — is the metric that measures how long it takes your web server to start responding after receiving a request. It's separate from the time it takes the entire page to load, and it's often the overlooked performance variable that explains why two websites with similar file sizes can load at dramatically different speeds.

TTFB is determined almost entirely by server-side factors — the hosting infrastructure's response speed, the efficiency of the server-side processing required to generate the page, and the network distance between the server and the user. Browser caching and CDNs can help with subsequent loads but don't meaningfully affect TTFB on the first request, which is often the most important one for conversion — a new visitor who has never loaded your page before experiences your server's raw response time without any caching benefit.

The hosting infrastructure component is the most directly controllable variable for most website owners. The difference in TTFB between a well-configured shared hosting environment with SSD storage and proper resource allocation, and an oversold cheap hosting plan on older hardware with many competing accounts, is typically measured in hundreds of milliseconds to full seconds. This difference matters for both search engine ranking — Google uses page speed including TTFB as a ranking signal — and for conversion rate, where every additional second of loading time consistently correlates with higher bounce rates.

The server-side processing component is primarily about how efficiently your website's code generates pages. WordPress sites that have accumulated many plugins or that run without appropriate caching generate pages slowly not because of the hosting but because of unnecessary processing on every request. Object caching — storing the results of expensive operations rather than repeating them on every request — is a configuration that reliable hosting providers typically support or include, and it can dramatically reduce the server-side processing component of TTFB.

The geographic distance component is what CDNs address for static assets, but TTFB for dynamic pages still depends on the distance between your user and your origin server. A hosting server in India serves Indian visitors with lower TTFB than it serves visitors in Europe, regardless of how good the hosting is. This matters primarily for sites with significant international traffic; for locally-focused businesses with primarily local visitors, choosing a hosting provider with servers in a geographically appropriate region is the right optimisation.

Measuring your TTFB specifically — using tools that test from multiple geographic locations and separate TTFB from total load time — gives you accurate diagnostic information that general speed scores don't provide. Knowing your TTFB is 1.2 seconds while your total load time is 3.8 seconds tells you that the server response is contributing about one-third of the total load time, which directs optimisation effort toward the server side rather than toward asset optimisation that might produce less improvement.