Kort svar: Tag et snapshot af køens antal, ældste request, type og status, og kontroller derefter QUIC.cloud Page Optimization-status og resterende quota. En request sendes i batch til QUIC.cloud, genereres på en service node og meldes tilbage til WordPress. Fejlen kan derfor være CSS-syntax/timeout, blokeret REST/callback, WP-Cron eller manglende quota. Tryk ikke Force cron gentagne gange; det kan skabe flere requests uden at rette det trin, der fejler.
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, LiteSpeed Cache 7.9, PHP 8.4.23 og Chrome 151 på isoleret staging. QUIC.cloud-integration, Page Optimization-kø og quota er ikke aktiveret eller verificeret; tidsserien og requestens status skal derfor måles i din egen konto.
CCSS, UCSS og VPI sendes som page-optimization-requests. En “pending” række kan vente på batch/cron, QUIC.cloud-behandling eller WordPress-pickup. Mål status over tid og find det første fejlede trin.
På denne side
| Trin | Bevis | Typisk fejl |
|---|---|---|
| WordPress opretter request | LiteSpeed queue med URL/type | Hook/indstilling opretter intet |
| Batch sendes | Request timestamp/service status | WP-Cron/outbound HTTPS |
| QUIC.cloud genererer | Dashboard recent request | Quota, syntax, timeout, nodefejl |
| QUIC.cloud callback/pickup | REST/HTTP-log | WAF, security, wrong domain |
| WordPress gemmer resultat | CCSS/UCSS-fil/status | Permissions/disk/cache |
| Cached HTML bruger resultat | Source/asset/header | Gammel page cache |
Notér CCSS/UCSS/VPI hver for sig: total pending, failed, complete, ældste alder og en repræsentativ test-URL. Gem også LiteSpeed-/WordPress-/PHP-version. En kø med mange nye URL-varianter kan være stor uden at være fastlåst; sammenlign igen efter 15 og 60 minutter.
En kø er ikke dokumenteret fastlåst, blot fordi den ikke er tom. Se på gennemløb: bliver ældste request nyere, stiger complete, og falder pending uden manuelle klik? Registrer tre målinger med samme felter. En langsom kø flytter sig; en fastlåst kø har samme ældste request og samme første fejlede trin gennem hele observationsvinduet.
Nye publiceringer, sitemapvariationer eller en purge kan samtidig oprette requests hurtigere, end de behandles. Sammenlign derfor både indgang og udgang. Hvis complete stiger, mens pending også stiger, er problemet kapacitet eller variationsmængde, ikke nødvendigvis callback. Stop nye massepurges, og test én kendt URL separat.
| Symptom/mønster | Sandsynlig årsag | Kontrol | Næste handling |
|---|---|---|---|
| Pending falder, complete stiger | Køen arbejder normalt | Tre tidsmålinger | Vent og undgå force |
| Pending stiger, complete stiger langsomt | Tilførsel er større end kapaciteten | Nye requests kontra completes | Begræns nye varianter/requests |
| Samme request bliver failed | Deterministisk URL-/CSS-fejl | Request-ID og redigeret fejl | Ret den konkrete fejl og gentest én URL |
| Dashboard complete, WordPress pending | Callback/pickup/lokal status fejler | REST, cron og lokal fil | Ret første manglende returtrin |
| Ingen request i dashboard | Batch/outbound stopper før service | Lokal kø, cron og HTTP-log | Ret cron eller outbound HTTPS |
Vælg en enkel, offentlig URL med stabil HTML og uden personlige data. Purge kun dens genererede optimeringsresultat, opret én ny request og følg dens ID/type gennem hele kæden. Hvis den virker, mens en kompleks side fejler, ligger forskellen sandsynligvis i CSS, render-tid eller URL-variant. Hvis også den enkle side stopper før dashboardet, ligger fejlen i forbindelsen eller runneren.
Brug ikke forside, checkout og ti templates samtidig som første test. En lille reproduktion beskytter quota, mindsker belastning og gør det muligt at koble loglinjen til den synlige request. Gem ikke fulde dashboard- eller kontoscreenshots i artiklen; beskær til status, type og redigeret request-ID.
I QUIC.cloud Page Optimization ses seneste requests, service-status og fælles quota for CCSS, UCSS og VPI. En suspenderet service ved opbrugt quota kræver en bevidst prioritering eller ventetid — ikke firewallændringer. Del ikke kontobalance eller account-ID i offentlige screenshots.
Hvis tjenesten er nede, bevar køen og stop gentagne force-forsøg. Test igen efter dokumenteret servicegenoprettelse.
Syntax error peger på original CSS-fil og en position/beskrivelse. Ret originalfilen på staging og opret en ny testrequest. En timeout kan skyldes langsom origin, blokering eller en side, der ikke kan renderes korrekt for service-noden.
Gem kun filsti og redigeret fejltekst. CSS kan indeholde licenseret eller kundespecifik kode; del den mindst mulige relevante blok med ejeren.
QUIC.cloud skal kunne hente/render og give resultatet tilbage. Kontroller WordPress Site Health, REST API, security plugin, WAF og aktuelle dokumenterede QUIC.cloud-IP'er. En 401/403/5xx eller timeout ved samme UTC-tid er bedre bevis end køens UI-status.
Hvis en reverse proxy skjuler eller ændrer origin, brug det dokumenterede integrationsflow. Slå ikke hele sikkerhedslaget fra permanent.
Baggrundsgenerering og pickup kan vente på cron. Se Site Health og cronlog efter fejl. På lavtrafik-staging kan webbaseret WP-Cron køre sjældent; en rigtig server-cron kan være relevant, men må ikke indføres uden at kontrollere den eksisterende runner og DISABLE_WP_CRON.
Force cron bruges én gang efter at den konkrete blokering er rettet, og kun for en lille testkø. Mål CPU/PHP og stop ved belastning.
Et resultat kan være genereret, men ikke gemt på grund af rettighed/diskfejl. Eller CCSS/UCSS-filen findes, mens gammel HTML stadig peger på tidligere output. Kontroller den berørte fil/status og purge derefter kun relevant CSS/page cache.
Purge All igen og igen, før filen findes, kan forlænge fejlen og udløse nye requests.
Kontroller ledig diskplads og filens faktiske ændringstid uden at vise serversti eller brugernavn offentligt. Hvis WordPress-status siger complete, men filen mangler eller ikke kan læses anonymt, er problemet lokalt efter QUIC.cloud-behandlingen. Hvis filen findes, men source stadig henviser til en gammel hash, er page cache eller templateoutput næste ejer. Gem denne forskel; den afgør, om hosting, pluginet eller QUIC.cloud skal have sagen.
Sprog, mobil cache, Guest Mode, cache varies og separate post types kan skabe mange CCSS/UCSS-varianter. Kortlæg hvilke der reelt er nødvendige. Slå ikke varianter sammen, hvis de har forskelligt layout eller personligt indhold; fjern kun overflødige varianter efter visuel test.
Det mønster viser, at service-noden sandsynligvis har behandlet requesten, mens returvejen eller den lokale anvendelse mangler. Se efter callback eller pickup på samme request-id, derefter filens status og skrivemulighed. Hvis resultatfilen findes, men HTML stadig bruger en gammel hash, er page cache næste lag. Du skal ikke sende requesten til generering igen, før returtrinnet er undersøgt.
Det omvendte mønster — lokal kø uden request i dashboardet — peger tidligere i kæden. Kontroller runner, WP-Cron, outbound HTTPS og om batchen overhovedet blev sendt. At hæve quota løser ikke en request, som aldrig nåede tjenesten.
Kortlæg templates og variationer, før du regenererer alt. En forside, centrale landingssider og de mest brugte artikeltemplates er normalt vigtigere end parameter-URL'er og sjældne arkiver. Fjern kun dokumenteret overflødige variationer; mobil, sprog eller medlemsstate kan have reelt forskelligt layout.
Hvis en enkelt kompleks URL fejler med CSS-syntax eller timeout, isoleres den fra den øvrige kø. Ret originalfilen eller renderingstiden og test netop den URL. En massegenstart kan ellers bruge quota på sider, der allerede var korrekte, og skubbe det egentlige fejlpunkt længere ned i listen.
Force cron bruges højst én gang efter en konkret blokering er fjernet. Stop hvis pending vokser uden completes, hvis CPU/PHP-kø stiger markant, eller hvis samme request igen får samme fejl. Gem målingen. Gentagne klik uden ændret input er ikke en ny test; de er blot flere kopier af den samme fejlsituation.
Stop ny force-/server-runner, gendan tidligere optimeringsindstilling, og fjern midlertidige firewallregler. Bevar kø/logs til diagnose. Ved akut layoutfejl deaktiveres den ene berørte CSS-optimering, mens resten af cache kan fortsætte.
QUIC.cloud skal have domain/report-ID, service request, type, tidspunkt og redigeret fejl. Hosting skal have REST/HTTP-status, cron og fil-/permissionfejl. Se LiteSpeed hosting hos Hostious ved origin-/runnerproblemer.
Enten venter requesten reelt i kø hos QUIC.cloud (normalt ved travlhed), quotaen er brugt, eller callbacket tilbage til dit site fejler, så resultatet aldrig registreres. Status og quota i dashboardet afgør hvilken.
Nej – hvert nyt forsøg laver en ny request og kan stille dig længere bagud. Send ét nyt forsøg EFTER at årsagen (quota, callback, CSS-fejl) er ryddet af vejen.
Vent til den fornys, køb credits – eller reducér forbruget: færre skabeloner med UCSS, færre regenereringer og ingen unødvendige purge-all, der udløser nye genereringer.
Tag tre statusmålinger med tidspunkt, pending, complete, failed og alderen på den ældste request. Gem én redigeret request-id gennem hele livscyklussen og knyt den til REST-, cron- og filstatus. Skjul konto, domæne og kvotebeløb i materiale, der deles offentligt.
Efter rettelsen skal en ny, afgrænset testrequest gå fra queued til complete, blive gemt lokalt og faktisk bruges i anonym HTML. Eksempelforløbet er en metode – ikke et måleresultat. Din egen kø og quota ser du i QUIC.cloud-dashboardet.
