articulus Directory
Difficulterne eligis genus insertionis aptum pro W3 Total Cache Minify? Hic articulus experientiam realem moderatoris paginae communicat et ducem gradatim praebet ad accurate eligendum genus insertionis Minify aptum, vitando casus stili situs interretialis et ruinas onerationis. Praeterea includit solutionem configurationis infallibilem quam etiam novitii facile adhibere possunt, experientiam WordPress lenem et celerem praebens !
Situs interretialis optimizabam, et cum optiones Minify in W3 Total Cache aperui, prorsus obstupui. Index verticalis pro typo incluso quattuor optiones habebat: "Default (Block)", "Use JS for Non-Blocking", "Use "Asynchronous" for Non-Blocking," et "Use "Delayed" for Non-Blocking.
Paulisper de hac re cogitavi, quid haec omnia sunt?
Crede mihi, non es solus. Hae quattuor optiones etiam tyronem fortasse perturbatum relinquent, nedum aliquem qui WordPress annis usus est. Hic articulus insidias quas expertus sum et lectiones quas directe didici exhibet. Non opus est tibi documenta consulere; modo instructiones meas sequere.
Quidnam accurate sunt hi quattuor modi incorporationis?
Primum de genere personae hae quattuor optiones disseramus.
Clausura implicita est via simplicissima. Cum navigatrum scriptum invenit, sistit, scriptum deponit et plene exsequitur, deinde paginam reddere pergit. Fidele sonat, nonne? Sed compromissum est quod prima pagina oneratio differetur; usores exspectare debebunt dum scriptum currere perficiatur antequam quicquam videre possint.
Usus JavaScript ad non-obstructionem satis interesting est. Loco inscriptionum `<script>` directe in pagina, primum parvum scriptum producit, deinde scripta necessaria dynamicē in paginam per JavaScript iniicit postquam pagina currit. Hoc modo, pagina primum redderi potest, et scripta paulatim onerantur. Optime sonat, nonne? Sed problema est quod hic processus injectionis dynamicē ordinem originalem executionis scriptorum perturbare potest. Si quaedam scripta in pagina tua magnopere in ordine executionis nituntur, problemata oriri possunt.
Adhibitio vocabuli "asynchronous" ad executionem non-obstruentem simpliciter significat attributum `async` ad notam `<script>` addere. Scriptum asynchrone in curriculo detrahetur et statim post completionem exsequetur, pagina non exspectante. Incommodum autem est quod ordo executionis omnino incontrollabilis est; quidquid primum detrahitur exsequitur, quocumque ordine in codice specificas.
Usus "morae" ad executionem non-obstruentem efficitur per additionem attributi `defer`. Scriptum exspectabit donec tota pagina retractata sit antequam exsequatur, et, quod magni momenti est, ordinem originalem quo scripsisti servabit. Hoc satis facile est usui, cum neque primam paginam obstruat neque ordinem scripti perturbat.
Utrum eligere debeam?
Simpliciter dictum, hae quattuor optiones similes sunt quaestioni multiplici electione: celeritatem vis an ordinem?
Mea suggestio haec est:
Si situs tuus parvus est, pauca scripta habet, et non habes requisita altissima celeritatis onerationis, optio implicita (obstructa) uti facillima est. Quamquam paulo tardior est, nulla problemata causabit.
Si celeritatem primae paginae augere vis et scripta tua non habent dependentias fortes sicut "A ante B exsequi debet," "differre" pro executione non impediente praefer . Haec fere est solutio idealis quae nunc praesto est, cum impedimentum reddendi vitat dum ordo executionis servatur.
Si, postquam "deferre" conatus es, functiones adhuc difficultates habere inveneris, tum JavaScript ad non-obstruendum uti considera . Haec methodus vehementior est, sed eius compatibilitas paulo peior.
Usus "async" ad non-obstruendum est optio quam minime commendo. Quia ordo executionis omnino confusus est, facile est corruere nisi omnino certus sis tua scripta separatim currere.
Duae magnae foveae in quas incidi
Loqui vile est. Duo errata quae feci scripsi; ea cum tua experientia comparare potes ut videas an vitare possis.
Primum impedimentum: Themata WordPress consuetudinaria in tempore reali praevisibilia esse non possunt.
Aliquamdiu, cum thema mutarem, postquam "servare" premerem, praevisio non renovabatur. Mutationes quasdam faciebam, paginam renovabam, et adhuc eadem manebat.
Post investigationem aliquam, inveni functionem compressionis Minify causam esse. Solutio simplex est:
Ad generales optiones extensionis W3 Total Cache vade , optionem "Compression" inveni , et eam notam remove. Deinde, sagittam parvam infra "Save Settings" in angulo dextro superiore preme, et " Save Settings and Clear Cache " elige. Hoc gradum magni momenti est; sine purgatione celae, versionem antiquam adhuc videbis.
Postquam perfeceris, ad customizationem thematis reverte, et praevisio viva ad statum normalem redibit.
Alterum problema: Arca inquisitoria thematis Astrae non respondet cum premitur.
Hoc problema iam pridem expertus sum. Themate Astra utebar, et quodam die subito inveni capsam quaerendi non respondere, quoquo modo eam premerem. Primo, putavi problema cum ipso themate esse, sed postea inveni causam ex optionibus Minify W3TC ortum esse.
Solutio haec est:
Ad W3 Total Cache → General Settings → Advanced Compression Settings → JS → Minify Engine Settings → Locale Settings vade, et genus incorporationis ad unum ex his duobus muta:
- Antehac, non-obstructio per JavaScript efficiebatur.
- Post, JS ad non-obstruendum utere.
Similiter, purgando memoriam celatam et paginam renovando, arca inquisitoria recte fungi poterit.
Quod ad causam cur hae duae optiones prae aliis electae sint, investigationem feci. Simpliciter dictum, partes frontales thematis Astrae ad tempus exsecutionis scriptoris satis sensibiles sunt, et quaedam modi non-obstruentes nexum eventuum deficere possunt. Usus modi "non-obstruentis cum JS" efficit ut scriptum solum postquam pagina onerata est exsequatur, dum executionem inordinatam, quae cum async videtur, vitat.
Index locorum visitandorum
Tandem, ecce index quem directe sequi potes:
Primum gradum est propositum tuum declarare. Visne celerrimam paginam initialem onerandam, an stabilitatem et operationem sine erroribus praefertis? Hoc determinabit quem genus insertionis uti debeas.
Secundum gradum est non omnia simul mutare. Primum, paginam minus magni momenti inveni ut eam probes, eam per diem unum aut duos observa, et eam toti situ tantum promove si certus es nullas difficultates esse.
Tertio, semper memoriam celatam post singulas modificationes purga. Mechanismus memoriae celatae W3TC te impediet quominus mutationes recentissimas videas, ergo gradus "purga memoriam celatam et iterum experire" omnino necessarius est.
Quarto, instrumentis navigatoris tui ad creationem paginae vel instrumentis sicut PageSpeed Insights utere ad celeritatem onerandi ante et post comparandam. Sine ut data pro se loquantur, non solum sensus tuus.
Scribere ad finem
Ut vere dicam, cum primum hanc optionem typi inclusi vidi, diu obstupui. Modus obstructionis implicitus nimis tardus videbatur, dum modus asynchronus ordinem non praestabat, et dilatio fortasse difficultates compatibilitatis causaret. Incertus eram quam optionem eligerem.
Sed postea intellexi compromissum esse. Non potes habere celerrimum et stabilissimum; semper unum sacrificandum est. Mea experientia est primum "defer" uti, quae nunc est solutio non-obstruens tutissima, deinde "callback" uti si difficultates oriuntur.
Si similia problemata offendis, aut si alias difficultates post meam methodum secutum adhuc habes, libenter de iis dissere. Elaboratio situs interretialis tota in experimentis et erroribus est; nemo exceptio est.
Gratias tibi ago quod articulum meum legisti. Te iterum videbo.
Spero fore ut tibi utilis sit articulus ille "W3 Total Cache Minify Plugin Settings: How to Choose the Embedding Type? My Pitfalls and Lifesaving Advice" in diario Chen Weiliang ( https://www.chenweiliang.com/ ) communicatus.
Libere hunc articulum communicare potes: https://www.chenweiliang.com/cwl-34003.html