Need 5 veidrat trikki teevad su WordPressi kiiremaks

Aidates iga nädal aeglaselt avanevaid ja otsirobotite koorma all ägavaid veebe elule äratada hakkavad mõned asjad korduma. 5 peamist nippi sai Tallinn WordPress meetup’i tarbeks ka ettekandeks vormistatud.

Ja ei ole need trikid tegelikult nii veidrad midagi – kui korra ära õpid ei saa enam ilma hakkama. Alustama peame aga natuke kaugemalt, sest mistahes probleemi lahendamine algab selle olemuse mõistmisest ja veebiserveri puhul ei saa me läbib logide ja serveri koormuse uurimiseta. Ning selleks on abiks võtta kasutusele SSH … ehk käsurida.

Sissejuhatus – kasuta SSHd

Käsurealt saad reaal-ajas vaadata aktiivseid protsesse, andmebaasi- ja veebi-päringuid, samuti otsida huvipakkuvaid mustreid kuitahes suurtest logifailidest, mille FTPga alla-lohistamine võtaks aega ja mis tavapärased tekstiredaktorid kokku jooksutaks.

Millest pihta hakata? Kui kasutad Mac OSi või Linuxit on mugavaim õpetus GitHubi Generating a new SSH key and adding it to the ssh-agent, mina googeldan abi vajades alati “github ssh key“… aga kui soovid Windowsi, PuTTY ja Zone-spetsiifilisemat abi, siis leiad ka meie abitekstidest juhise SSH ühenduse loomine.

Ma olen täiesti kindel, et kui õpid alljärgnevate supervõimete nimel SSHd kasutama… siis järgmine kord kohtudes teed mulle (oma eelistusest lähtuvalt) välja koogi või õlle 🙂

Trikk #0 – vaata logisid!

Nii, mis meil siin serveris siis toimub?

cd domeenid/www.example.com/logs/
tail -f apache.ssl.access.log | grep-php

Käsk tail kuvab faili lõppu ja -f värskendab väljundit jooksvalt, | grep-php otsib tulemusest päringuid, mis käivitasid PHP ehk veebirakenduse:

Nagu näha käib pidev lammutamine wp-login.php kallal, lisaks hakkavad silma wp-cron.php ehk ajastatud tegevused ja hulk erinevaid (otsi)roboteid: Yandex, Bing, DuckDuckGo, Ahrefs, Semrush… Õnneks on minu veebis rea lõpus olev ajakulu suurusjärgus 0.02-0.15 sekundit ehk olematu, aga kui aeg hakkab olema üle sekundi… siis võivad botid kergesti kurja teha.

grep-php, grep-phpslow ja grep-phpveryslow on Zone serverites seadistatud aliased, mis aitavad leida PHP- või aeglase PHP-päringuid. Kui tahad neid seadistada oma arvutis või mujal, siis käsk alias näitab retsepti 🙂

Trikk #1 – asenda wp-cron.php süsteemse cronjob’iga

Aga proovime ühte teist saiti ja grep-phpslow annab sellise tulemuse:

Ouch! 10-50 sekundit töötav cron-päring hõivab ühe veebi teenindamiseks mõeldud PHP-protsessidest… mõistlikum oleks seadistada süsteemne CRONTAB.

Sellest räägib eraldi help.zone.eu artikkel WordPressi cron-tööde seadistamine.

Trikk #2 – piira robots.txt abil botte

Kuigi robots.txt on rangelt soovituslik tuleb nentida, et suur hulk logides silma hakkavaid botte käituvad igati viisakalt ehk loevad vähemalt kord nädalas robots.txt faili ja arvestavad selle suunistega.

Minul on tavaks soovitada kõigil robotitel mitte pärida sagedamini kui 10 sekundi takka ning keelata päringud, milles sisaldub ? ehk millele on lisatud mingid parameetrid, olgu selleks siis s=otsisõna või color=pink&size=42 kujul e-poe filtrid.

User-Agent: *
Crawl-delay: 10
Disallow: /*?*

User-agent: AhrefsBot
User-agent: AhrefsSiteAudit
User-agent: SEMrushBot
User-agent: SemrushBot
User-agent: SemrushBot-SA
User-agent: MJ12bot
Disallow: /

Täiendavalt võib keelata meie jaoks väärtust mitte omavad botid, nt kui me ei kasuta Ahrefs ja Semrush SEO-tööriistu on kogu nende tekitatav koormus vesi vaid konkurentide veskile… ja miks neid nuumata?

robots.txt puhul tuleks meeles pidada, et tühi reavahetus ei ole ilu pärast vaid eristab erinevatele bottidele suunatud plokke ja User-Agent: * reegel kehtib vaid neile, kes endale sobilikku plokki ei leia.

Trikk #3  – kiireks ja jõuliseks piiramiseks kasuta .htaccess’i

Vahel ei pruugi aga robots.txt piisav olla, sest seda kontrollitakse periooditi samas kui sinu koormuse-probleem on valus just täna. Kuna viisakad botid panevad oma nime User-Agent’isse kirja, siis saab veebiserverile anda korralduse neile sobilikku veateadet näidata.

Selleks tuleb veebi juurkataloogis olevasse .htaccess faili lisada nimekiri soovimatutest User-Agent’itest ning lubada neile ligipääs ainult robots.txt’ile – lootuses, et nad tulevikus sellega arvestama hakkavad:

RewriteEngine On
RewriteCond %{REQUEST_URI} !/robots.txt$
RewriteCond %{HTTP_USER_AGENT} Semrush [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} AhrefsSiteAudit [NC,OR]
RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC]
RewriteRule .* - [R=503,L]

Trikk #3b – piira hiinabottide ligipääs

Kohati kohtab aga eriti agressiivseid botte, mis tulevad hulgalt erinevatelt IPdelt, ei huvitu robots.txt’ist ega evi äratuntavat UserAgent’it.

Aga sageli tulevad nad Hiina IP-aadressidelt. Zones on veebiserver seadistatud nii, et igal päringul on automaatslet küljes IP-aadressile vastav maakood, miska on lihtne lisada .htaccess faili järgmine plokk:

SetEnvIf MM_COUNTRY_CODE ^(CN) countryBlock
Deny from env=countryBlock

Ehk kui maakood algab CN’iga, siis Deny.

Vähendab kindlasti olulisel määral müüki Hiinasse, aga küllap tulevad hiinlaste hordid Helsinki lennujaama ja Talsinki tunneli kaudu peagi ise kohale, seega no harm done.

Trikk #3c – brauseri-cache ilma pluginata

Kui see .htacces juba editoris lahti on… teeks veel ühe pisiparanduse. Nimelt saab väga lihtsalt brauseritele öelda, et ei ole vaja igal lehekuvamisel käia küsimas kas mõni pilt või CSS on muutunud:

<IfModule mod_mime.c>
# Add mime types that might be missing from server conf
    AddType font/woff2 .woff2
</IfModule>

<IfModule mod_expires.c>
# Enable expirations
  ExpiresActive On
# Default directive
  ExpiresDefault                 "access plus 1 day"
# HTML
  ExpiresByType text/html        "access plus 0 seconds"
# Data
  ExpiresByType text/xml         "access plus 0 seconds"
  ExpiresByType application/xml  "access plus 0 seconds"
  ExpiresByType application/json "access plus 0 seconds"
# Favicon
  ExpiresByType image/x-icon     "access plus 1 year"
# Images
  ExpiresByType image/gif        "access plus 1 month"
  ExpiresByType image/png        "access plus 1 month"
  ExpiresByType image/jpg        "access plus 1 month"
  ExpiresByType image/jpeg       "access plus 1 month"
  ExpiresByType image/webp       "access plus 1 month"
# CSS
  ExpiresByType text/css         "access plus 1 hour"
# Fonts
  ExpiresByType font/woff        "access plus 1 year"
  ExpiresByType font/woff2       "access plus 1 year"
# Javascript
  ExpiresByType application/javascript "access plus 1 year"
</IfModule>

Trikk #4 – vaata, mis wp_options tabelis toimub

WordPressi puhul võiks edasi liikuda mitmes suuna – pagebuilder? WPML? turvaplugin? megamenüü? … aga jätame need hilisemaks. Kogenud koristaja võtab esimes asjana ette wp_options tabeli, sest:

  • sinna salvestatakse vaikimisi kogu “ajutine” kraam nn transient’idena;
  • transientide suurus võib olla kuni 100 megabaiti – ja seda siis üks kirje!
  • neid kirjeid või olla kümneid tuhandeid;
  • ja isegi kui progejad on arvestanud aegumise järel kustutamisega… võib see käia wp-cron’ile üle jõu;
  • seal on veerg autoload mis ei ole indekseeritud, ehk igal lehekuvamisel peab SQL otsima kümnete tuhandete ridade hulgast neid, mille indekseerimata väärtus on yes;
  • kirjeid võidakse uuendada igal päringul või ajastatud toimingul, mille tulemusena kasvab andmebaas kontrollimatult (à la 1 ööga 100 gigabaiti).

Ehk kui wp_options on suurem kui ca 1500 kirjet ja kirje sisu üle … ütleme, et üle max mõnesaja kilobaidi, siis on tegemist olulise probleemiga.

Trikk #5 – vaata, mida kood teeb

… see blogipostitus on olnud mustandi olekus täpselt 3 kuud – sest ma ei jõudnud 5nda triki kirjutamiseni esimese hooga. Aga ma arvan, et ma tahtsin kirjutada oma varasema Miks mu veeb aeglane on? Vaata BlackFire abil järgi! artikli lihtsamaks.

Kahjuks… seda lihtsamaks kirjutada väga ei anna. Sest kõige olulisem oleks pikk nimekiri “kuidas tõlgendada/lahendada olukoda X?” … ja meie mõlema jaoks oleks mõistlikum aja/rahakasutus kui ma konkreetse juhtumi (raha eest) ette võtaks ja arendajale juhised annaks.

Trikk #6 – tule Pop-up Helpdeski!

Enamvähem igal esmaspäeval kell 15-19 olen ma SpringHub’is ja aitan kõiki, kes viitsivad kohale tulla ja küsida.

Kontrolli igaks juhuks Zone FB lehelt ürituste sakist konkreetse kuupäeva toimumine järgi (sest vahel olen ma lähetuses või esinen mõnes teises kohas) ja võimaluse korral anna oma tulekust enne teada (ma olen kõigis sotsmeediakanalites petskratt), siis oskan aega planeerida.

Teeme postkastid suuremaks

Paras aeg on põrmustada pisikesi pehkinud paradigmasid, parandades põhimõtteid mille alusel veebimajutusteenuse klientidele e-posti pakume.

Umbes aasta tagasi kirjutasin siin Zone poolt kasutusele võetud unikaalsest e-posti platvormist, mille abil muutus meie vastav infrastruktuur töökindlamaks, turvalisemaks ja efektiivsemaks. Täna on samuti põhjust kritseldada olulisest muutusest, mille üheks võimaldajaks seesama platvorm.

Lühidalt, edaspidi saavad kõik meie klientide loodud postkastid juba vaikimisi olema neile teenuspaketis ette nähtud maksimumsuurusega. Teenuspakettide hind ja muud tingimused jäävad samaks, aga postkastide lisamine ja haldamine muutub lihtsamaks.

Lisaks saavad professionaalsed e-posti kasutajad enda käsutusse kaks uut, just neile sobivat postkastitüüpi, mis võimaldavad neile pakutavaid ressursse veelgi kasvatada. Virtuaalserveri teenuses vaikimisi sisalduvast postkastist eristab neid suurem andmemaht ja asjaolu, et see maht on individuaalne – see ei ole kuidagi mõjutatud veebimajutusteenusest ega avalda tollele mingit mõju.

Kõik uuel platvormil postkastid on kindluse huvides jätkuvalt kolmekordse liiasusega mitme andmekeskuse vahel hajutatud.

Miks me seda teeme?

Ajalooliselt oleme pidanud oluliseks, et klientidel oleks võimalik äärmise täpsusega oma ressursse lõppkasutajate, kes postkaste reaalselt kasutavad, vahel jagada. Selle mõtte juured peituvad ajastus, mil interneti eesmärk oli ühendada akadeemilisi organisatsioone – nende UNIX süsteemides olid kõik tudengitele ja teaduritele eraldatavad ressursid rangelt arvel ja kõik neile kulutatud sendid täpselt loetud. Kuna Zone sisekultuur tuleneb omal moel samuti sellest ajastust, oleme endale teadvustamata seda traditsiooni edasi kandnud.

Juba mõnda aega on siiski selge, et meie kliendid ei soovi enam tegeleda infotehnoloogiliste ressursside peenhäälestusega. IT vahendid on pilvetehnoloogiate arengu ja ühiskonna üldise heaolu kasvu toel muutunud odavamaks kui aeg, mis nende täpsele tuunimisele kuluks.

Seepärast olemegi täheldanud, et granulaarne postkasti mahu sättimine ei leia enam kasutust.

Viskame siis oma pehkinud põhimõtte ajaloo prügikasti. Edaspidi pole vaja virtuaalserverite haldajatel käia postkastide piirmäärasid arvutamas, jagamas ja seadistamas. Iga postkast saab vaikimisi endale täpselt teenuspaketis ette nähtud maksimumpiirmäära. Lisaks, kui postkasti kasutaja soovib midagi enamat, piisab vaid ühest lisaklikist ja väikese lisatasu eest voolab individuaalset andmemahtu juurde, nagu küllusesarvest.

Suure postkasti illustratsioon

Veel üks asi…

Suuremad postkastid esitavad loomulikult palju suuremaid nõudmiseid e-posti klientidele millega neid kasutada. Muuhulgas on ka see pannud meid tööle selles suunas, et arendada asendus tänasele Zone veebipõhisele e-posti kliendile. See pingutus on nüüd kandmas esimesi vilju, mis valmis lõppkasutajatele tutvumiseks ja aadressil https://webmail.ee on võimalik meie uue e-posti platvormi kasutajatel sellega vaikselt tutvust teha.

Uuest veebipõhisest e-posti lugemise kogemusest peagi veidi pikemalt.

Kui tahad kontrollida, kas oled Zone uue e-posti platvormi kasutaja, saad seda teha aadressil https://help.zone.eu/kb/e-posti-serverid/. Uuel platvormil klientidel on IMAP serveri nimeks imap.zone.eu.

Internet Society müüs .ORG tippdomeeni maha

Kas mäletate veel aega, mil riigitähisega tippdomeenile (nagu .EE) oli peamiselt kolm alternatiivi: kommertsettevõtmisi tähistav .COM; võrguinfrastruktuuri- ja internetiga seotud .NET; ja mittetulunduslikke algatusi ühendav .ORG? Meie mäletame.

Tänaseks on tippdomeenide arv plahvatuslikult kasvanud ja endale sobiva võib leida ulatuslikust geneeriliste domeenide valikust, mille ühes otsas värsked globaalsed gigandid nagu nagu .xyz ja teises nišidomeenid nagu .vodka või .plumbing. Domeeniuniversumi pulbitsedes on suur kolmik siiski püsinud suhteliselt stabiilsena.

Nüüd andis .ORG tippdomeeni registrit – Public Internet Registry (PIR) – seni üleval pidanud Internet Society (ISOC) avalikkuse jaoks ootamatult teada, et seni mittetulunduslik PIR müüakse maha uuele ja suhteliselt tundmatule investeerimisfirmale Ethos Capital: Ethos Capital to Acquire Public Interest Registry from the Internet Society | Internet Society.

.ORG tippdomeenis on registreeritud ligi 11 miljonit domeeni, mis teeb sellest maailma suuruselt seitsmenda tippdomeeni. Suurimad on jätkuvalt .COM (ca 155 miljonit domeeni) ja .NET (16 miljonit domeeni), kuid tänapäeval mahuvad nende ja .ORG’i vahele veel .DE, .TK, .CN, ja .UK.

Muutus toob tihti endaga kaasa ebakindluse, nii ka seekord. Esimese asjana kaotabki Public Internet Registry oma mittetulundusliku staatuse, mis muudab äärmiselt tõenäoliseks tulevase hinnatõusu, kuna uus omanik ootab kasumit. Lisaks oli PIR just hiljuti kaubelnud ICANN’ilt endale välja sisuliselt piiramatud võimalused hindade tõstmiseks.

Täpsema ülevaate ja ajaloo ICANN’i, ISOC’i ja PIR’i senistest suhetest leiate artiklist: How ICANN uses the .Org registry to fund the Internet Society – Domain Name Wire | Domain Name News.

.ORG tippdomeeni registri müügi hinda ei ole avalikustatud, kuid arvestades PIR’i senist käivet, mis olnud umbes 100 miljonit dollarit aastas ja sellelt teeninud 50 miljonist sissetulekut (millest seni ISOC’i tegevust on finantseeritud), on see ilmselt märkimisväärne.

Mis edasi saab, pole ilmselt keeruline ennustada. .ORG tippdomeeni registritasu oli 2002. aastal 6 dollarit ja on hetkel juba 9,93 dollarit. Tõenäoliselt hakkab see nüüd veel kiiremini kasvama. Nagu mõned valdkonna eksperdid muigavad, siis ostis Ethos Capital endale just raha trükkimise masina.

Hoiame nendel arengutel pingsalt ja murelikult silma peal, sest hinnatõuse on juba oodata  mitmetelt tippdomeenidelt ja ORG’i eeskuju võib teisigi nakata.

Milleks on kasulikud WordPressi laetud meedia alternatiivtekst, pealkiri, allkiri, kirjeldus jne?

WordPressi meediateegis tekitab segadust hulk infolahtreid: Alternatiivtekst, Pealkiri, Allkiri ja Kirjeldus. Kas ja mida sinna kirjutada?

Alustame vahest kõige olulisemast – Alternatiivtekst kirjeldab pilti ning seda näeb kui vaadata lehe HTMLi või WordPressi redaktoris sakki Tekst:

Ekraanilaks ekraanilaksust WordPressi redaktori teksti-sakis

Vaegnägijale loeb ekraaniluger selle teksti ette, seega võiks sisu olla ennekõike pilti kirjeldav. Lisaks jälgivad alt-teksti ka otsimootorid, ehk hästi kirjeldatud pilt on abiks ka SEO vaatest. Aga see ei ole veel kõik: alt-teksti kuvavad brauserid siis, kui pildifail mingil põhjusel ära kaob:

Ekraanilaks katkisest pildist brauseris

Tähtsuselt järgmine on pildi Allkiri ehk inglise keeles caption: see on pildi all kuvatav tekstilõik, kuhu sobib pikem selgitus, foto autor jms info. Nagu ülevalt koodinäitest näha on see realiseeritud [caption] koodiga ning teemades on enamasti paika pandud ka sobilik kujundus:

Ekraanilaks WordPressi meediateegist
See on pildi allkiri, ingl. k caption. Ekraanilaksu autor: Peeter Marvet

Pealkiri ja Kirjeldus on mõeldud manuselehe jaoks – nimelt tekitab WordPress iga üles laetud meedia-faili kohta alamlehe, millel kuvatakse Pealkiri, meedia ja Kirjeldus. Ülaloleva ekraanilaksu manuseleht on näiteks https://blog.zone.ee/2019/10/23/wordpressi-meedia-alternatiivtekst-pealkiri-allkiri-kirjeldus-jne/wp-pildi-kirjeldus/.

Manuseleht ei pruugi aga otsimootorist tulevate külastajate jaoks olla parimaks maandumisleheks – mina näiteks tahaks, et WordPressi meedia kirjeldamist puudutavate otsingute puhul saaks parima positsiooni see blogipostitus, mitte mõni ükskik ekraanilaks.

Selleks on näiteks Yoast SEO pluginas olemas võimalus suunata manuselehed automaatselt edasi pildifailile ehk sisuliselt ära kaotada:

Ekraanilaks: Yoast SEO plugina seaded

Ja ära unusta, et SEO jaoks omab lisaks alt-tekstile tähendust ka faili nimi. Siin artiklis olevad ekraanilaksud ilmselt ise-seisvat väärtust ei oma, aga toote-foto võiks muuhulgas Google pildi-otsingus välja tulla nii kirjeldava (“pink t-shirt powerpuff girl”) kui tootekoodi-otsinguga.

WordPressi haakimiskohad ehk konksud ja filtrid

Haak või kõrvalepõige on nagu nõudepeatus või küsimus “kas astun töölt koju tulles poest läbi?” ehk kellegi poolt kirjutatud koodi on taotluslikult jäetud võimalus selle kulgu mõjutada.

WordPressis on kahte sorti haakimiskohti:

  • hook e. konks on nagu nagi, kuhu igaüks saab riputada oma täitmist vajavad funktsioonid;
  • filter võimaldab huvilistel andmeid mudida, reeglina enne väljastamist.

Konksudest ja filtritest räägib kolmapäeval, 09.10.2019 kell 19 algaval WordPressi meetupil ka Arūnas Liuiza.
Tule kohale kuulama ja küsima!

Konks

Selle illustreerimiseks sobib alamteemade postituses olev näide, kus lisasin Google Analytics’i header.php koodi:

Kuna header.php sai kopeeritud alamteema kataloogi tuleb sellise laiendamise puhul arvestada, et kui põhiteemas see fail uueneb on vaja neid a) märgata b) käsitsi alamteemasse üle tuua.

Jätkusuutlikum lahendus on päise konks:

<?php wp_head(); ?>

See teeb täpselt ühte asja – kutsub välja kõik ennast wp_head konksu külge haakinud funktsioonid:

function wp_head() {
/**
* Prints scripts or data in the head tag on the front end.
*
* @since 1.5.0
*/
	do_action( 'wp_head' );
}

Praktikas haagivad ennast sinna kõik skriptid-CSSid-metaväljad jne (seejuures mõned nt JS ja CSS kasutades  spetsiaalseid konkse, mis ennast wp_head külge haagivad).

Sama analüütika-koodi saaksime lisada alamteema functions.php faili nii:

function petskratt_analytics() {
?>
	<!-- Global site tag (gtag.js) - Google Analytics -->
	<script async src="https://www.googletagmanager.com/gtag/js?id=UA-xxxxxx-1"></script>
	<script>
	  window.dataLayer = window.dataLayer || [];
	  function gtag(){dataLayer.push(arguments);}
	  gtag('js', new Date());
	
	  gtag('config', 'UA-xxxxxx-1');
	</script>
<?php
}

add_action('wp_head', 'petskratt_analytics', 1);

Kirjeldan funktsiooni ning haagin ta nime pidi add_action abil sobilikku kohta, viimane parameeter on prioriteet ehk vastavalt Google Analytics’i soovitusele tahaks nende jupp olla võimalikult <head> alguses. Päris esimeseks ei saa, aga need eelnevad meta-väljad ei ole ka kuidagi probleemiks.a

Nüüd võin ka Twenty Nineteen’i julgesti uuendada, minu alamteema muudab põhiteema ja WordPressi käitumist vastavalt parimale tavale.

Selliseid konkse on WordPressis umbes 800 – ja lisaks 1700 filtrit.

Filter

Konks on abiks, kui tahad ise midagi väljastada – aga mida teha juhul, kui tahaksid muuta mõne teise funktsiooni poolt väljastatavat? Näiteks prooviks postituse sisu kuvada AINULT SUURTÄHTEDEGA … või veel parem (jaburam) SuvaLIsE SuuRUsEGA.

Tegevuste ahel on selline:

  1. teema kutsub sobilikus kohas välja funktsiooni the_content()
  2. the_content() leiab andmebaasist postituse sisu, valmistab selle kuvamiseks ette… aga enne kuvamist pakub võimalust the_content filtri külge haakinud funktsioonidele seda muuta
  3. sinu funktsioon haagib ennast the_content filtri külge, teeb mida tahab ja tagastab tulemuse
add_filter( 'the_content', 'petskratt_rAndOmcASe' );
 
function petskratt_rAndOmcASe( $content ) {

	$str = str_split( strtolower( $content ) );

	foreach ( $str as &$char ) {
		if ( rand( 0, 1 ) ) {
			$char = strtoupper( $char );
		}
	}

	return implode( '', $str );
}

Ja tulemus näeb välja selline:

Fuksi värvi pealkiri on postitusest Kuidas kohandada WordPressi teemat ehk alamteema (child theme) kasutamine.