N1Nex1on
N1Nex1on

Security and speed

A faster site in one evening: 9 steps with a before and after measurement

25.10.2026 · NexVoid

9 мин чтения

Ready pages, compression, the styles a page needs, images, the schedule and OPcache: every step has three lines: what to do, how to check it with a number or a command and what happens if you skip it. With a measurement before and after.

A visitor does not wait: if a page opens slowly, they leave, and search engines take speed into account. The good news is that on most small sites the same things slow the page down, and you can fix them in one evening without changing the theme or the hosting. Below are nine steps. Each has three lines: what to do, how to check (a screen, a command or a number) and what happens if you skip it. We start and finish with a measurement so that you can see what helped.

The steps are independent, take any of them. One warning right away: the numbers below come from our own test stand, not from your site. Yours will differ, the direction is what matters.

Your panel: “What to improve” and “System health” #

Open “Site management → SEO & accessibility → What to improve” and choose the “Speed” tab: it lists what is not turned on yet on your site. And in “System → Diagnostics → System health” there is a “Recommendations” block at the bottom: it prompts about the cache, the schedule and OPcache.
“What to improve”, the “Speed” tab: the engine itself names what is not turned on yet
“What to improve”, the “Speed” tab: the engine itself names what is not turned on yet

Step 1. Measure first #

What to do. Open PageSpeed Insights, paste the address of your home page and run the check for a phone. Or in the Chrome browser: developer tools, the Lighthouse tab, “Analyze page load”. Write down three numbers: LCP (when the main part of the page appeared), CLS (how much the page “jumps”) and INP (how fast the site responds to a tap). The targets according to web.dev: LCP no more than 2.5 seconds, INP no more than 200 milliseconds, CLS no more than 0.1, and this for three visitors out of four (the 75th percentile). How to check. You have three written numbers and the date of the measurement. If you skip it. You will not know whether the changes helped. Remember two more things. The Lighthouse result varies from run to run: run it three times and take the middle one. And a score of 100 is not the goal: the Chrome documentation says it is extremely hard to reach and not expected, and the green zone starts at 90.

Step 2. Ready pages for guests #

What to do. In “Site settings → Speed and upkeep” turn on “Serve ready pages to guests”. A page built for one guest is served to the rest as is, with no database work. Signed-in people get their own pages as usual, and the cache clears itself on any change made in the panel. You can leave “How many seconds to keep” alone: five minutes (300) is enough. How to check. Request the home page twice:
Bash
curl -I https://example.com/
curl -I https://example.com/
The second answer should contain the line X-Nex1on-Cache: hit. On our test stand a page built anew was served in 0.6–0.8 seconds, and a ready one in 0.12–0.17.
“Speed and upkeep” settings: ready pages, HTML compression and image hints
“Speed and upkeep” settings: ready pages, HTML compression and image hints

If you skip it. Every guest makes the server build the page from the database again. On a busy site this takes most of the work off the server.

Step 3. Compress the HTML #

What to do. In the same place turn on “Compress HTML pages”: extra spaces, line breaks and comments leave the pages. The look does not change, the admin panel is not touched. If a page looks wrong after turning it on, turn it off. How to check. Compare the size of the answer before and after:
Bash
curl -s https://example.com/ | wc -c
On our test home page the answer shrank from 157 to 138 KB, by about 12 percent. HTML compression is more useful together with ready pages (step 2): without them the server compresses every page anew for every guest, and “System health” will remind you of it. If you skip it. Pages weigh more than they need to. Nothing breaks, you just pay extra kilobytes to every visitor.

Step 4. Only the styles a page needs #

What to do. Turn on “Only the styles a page needs”: instead of several full stylesheets the page gets one, with just the rules that can apply to it. The look does not change. How to check. Open the page source (Ctrl+U) and find rel="stylesheet". On our test stand three stylesheets (about 634 KB uncompressed) were replaced by one (157 KB). If you skip it. The phone downloads rules for pages it has not opened: the home page opens noticeably slower, especially on a mobile network.

Step 5. Images #

What to do. In “Site settings → Images and video” check three things. First: “Largest image width, px” is 0 by default, which means no limit. Set the number you really need (for example, 2000): large pictures are scaled down on upload with the same proportions. A photo six thousand points wide is too much for a column a thousand wide. Second: “Image compression”: by default it is “Locally”, and nothing leaves the site; the external TinyPNG service returns lighter files, but your picture is then sent to someone else's server. Third: turn on “Pictures in WebP too”: the site also keeps a lighter copy and serves it to the browsers that ask for it. Copies are made only for new uploads; for pictures already uploaded run the command php nex1on media:webp on the server. Leave “Image hints for the browser” on: the engine adds sizes, lazy loading below the first screen and priority for the main picture by itself.
“Images and video” settings: the largest width, compression and WebP
“Images and video” settings: the largest width, compression and WebP

How to check. See what the engine wrote into the page:

Bash
curl -s https://example.com/ | grep -o '<img[^>]*>' | head -3

The pictures should have width and height (the page does not jump while loading), srcset and decoding="async". The main picture on the first screen has fetchpriority="high" and no loading="lazy"; the ones lower on the page have loading="lazy". This is by design: web.dev warns directly against lazy-loading a picture that is visible at once, otherwise the page opens slower.
If you skip it. Pictures are usually the heaviest part of a page, and one unsuitable photo can outweigh everything else.

Step 6. Fonts #

What to do. The themes that come with the engine do not load fonts from a server: the text uses the fonts already on the visitor's device, so nothing is downloaded. If you still add your own font, follow the web.dev rules: the WOFF2 format, only the styles you need, font-display: swap (or optional) and do not preload everything. How to check. In developer tools, the Network tab, the Font filter: for a site with no loaded fonts the list is empty. If you skip it. Every added font is an extra file that blocks the text or makes the page “jump” when the font is swapped in.

Step 7. The schedule and OPcache #

What to do. Open “System → Diagnostics → System health” and look at the “Recommendations” block. If “Mail goes out when visitors arrive” is there, add a schedule (cron) on the hosting, once a minute: the recommendation itself shows the ready command. Then mail and background jobs are processed without visitors, and pages do not wait for mail. If “PHP OPcache is unavailable” is there, ask the hosting support to turn it on: OPcache keeps the parsed PHP in memory, and the server does not parse the same files on every visit. How to check. The corresponding rows in “Recommendations” disappear. If you skip it. The site does extra work on every visit, and you notice it only at peak hours.

Step 8. Instant page transitions (optional) #

What to do. Turn on “Instant page transitions”: when a visitor hovers over a link, the browser (Chrome and similar) fetches the page ahead of time, and the click opens it almost instantly. It works for guests and for pages already in the ready-page cache, so turn on step 2 first. Views and counters do not grow from preloading. The admin panel, sign-in, file downloads, e-mail confirmation links and addresses with a question mark are never preloaded. How to check. In developer tools, the Network tab: when you hover over a link, a request for that page appears in the list. If you skip it. Nothing terrible: it is a bonus, not a necessity.

Step 9. Measure after #

What to do. Repeat step 1 and compare the three numbers. To look not at lab data but at real visitors, turn on “Real speed for visitors”: the visitor's browser measures LCP, CLS and INP and sends only the numbers when they leave. IP addresses, cookies and browser details are not stored, bots and people who turned on “do not track” are not counted, visitor consent is usually not needed because there is no personal data, but check with a lawyer for your country. The results appear in “SEO & accessibility → Speed”. How to check. Three new numbers next to the old ones. A lab measurement shows one device and one network, while the real picture is what your visitors see, so when they disagree trust the second. If you skip it. You will be guessing instead of knowing.

What this list does not do #

It removes extra work, but it will not make fast what is heavy by nature: a very heavy theme, dozens of external widgets and counters, or an overloaded hosting. If the site is still slow after all the steps, look in the Network tab at what loads longest and start there.

← К ленте новостей

Поделиться: Telegram WhatsApp

Читайте также

Обсуждение

Комментарии

Обсуждение ещё не началось

Пока никто не высказался. Будьте первым.

Пожаловаться на запись