";?>

echo " WordPress: " Kolo (memory_get_usage () / 1024 / 1024, 2) . "MB" . " | MySQL: " . get_num_queries(). " | " ; timer_stop(1); echo "sek " ; ?>

Dotazy na MySQL Rychlost generování stránky Bez scénáře 11,68 MB 31 0,68 S MaxCache 0,82 MB 0 0,00025

Zatížení serveru se snížilo více než 14krát!

Počet volání databáze při použití skriptu je nula!

Rychlost generování stránek se zvýšila 2720krát!

Čísla jsou dobrá, ale i bez nich je rychlejší práce blogu vizuálně patrná. Stránky se otevírají mnohem veseleji.

Jak funguje skript pro ukládání do mezipaměti? Uživatel, který navštívil váš web, otevřel stránku, která ho zajímala, MaxCache ji okamžitě umístil jako statickou stránku do složky Cache. Nyní je dán uživatelům z této složky bez dotazů na databázi a bez dodatečného zatížení serveru.

Mezipaměť stránek se resetuje každé 4 hodiny. V případě potřeby můžete zadat vlastní nastavení.

Skript je dodáván s pluginem, který nám po aktivaci umožňuje zobrazit aktuální verze stránek bez mezipaměti, když jsme přihlášeni a pracujeme na panelu administrace blogu. Pro návštěvníky v tuto chvíli, podle očekávání, je skript načte z mezipaměti.

Je možné povolit kompresi provozu gzip. Zvyšuje rychlost načítání „těžkých“ stránek. Povolení komprese gzip zvyšuje zatížení serveru. Zda tuto funkci povolit nebo ne, je třeba rozhodnout na základě dostupnosti limitů zatížení CPU. Před povolením komprese gzip musíte u svého hostitele zkontrolovat, zda tuto funkci server podporuje.

Při psaní článků často používám obrázky a screenshoty na stránkách. Sice je stlačuji na maximum, ale váha, která vyjde, není vždy taková, jakou bych si přál. Mám povolenou kompresi gzip.

Výsledky pro hlavní stránku byly následující.

Před kompresí byla váha mé stránky 23,7 KB, po kompresi 6,5 KB. Úspora činila 72,4 %. Jak se říká - Bez komentáře. Testovací služba komprese gzip se nachází na této adrese - http://www.whatsmyip.org/http_compression/.

V samostatném souboru v nastavení skriptu můžete také určit seznam stránek se zákazem ukládání do mezipaměti. Po vydání nové verze skriptu je aktualizace pro všechny klienty zdarma.

Na závěr článku bych rád zdůraznil, že se mi líbí přístup autora scénáře k jeho prodeji. Po zaplacení MaxCache obdrží kupující verzi skriptu Lite. Tato verze má omezenou funkčnost. Od plné verze se liší tím, že se cache neresetuje automaticky. To znamená, že oříznutá verze funguje téměř stejně jako plná. Na testování autor vyčleňuje dva týdny času. Dále buď odmítnete nákup a autor vám vrátí peníze, nebo zašlete žádost o plnou verzi MaxCache.

Při nákupu tohoto zařízení, abych snížil zatížení serveru, jsem požádal, aby mi byla okamžitě zaslána plná verze, protože jsem byl již dlouho obeznámen s prací skriptu a byl jsem s jeho prací spokojen. MaxCache je ideálním řešením pro blog WordPress.

Téměř všechny mé weby běží na custom enginech, ale donedávna jeden z nich ještě běžel na dnes tak rozšířeném WordPressu. Faktem je, že wordpress byl původně nainstalován kvůli snadnému použití administračního panelu osobou provozující tento web (ne mnou). Ale po vydání řady verze 2.8 jsem si uvědomil, že už to tak není...

Zátěž hostingu se výrazně zvýšila, s počtem zásahů, dejme tomu 500-600, již Wordpress třikrát překročil limity na využití zdrojů MySQL, což znamená, že řešení bylo buď v mezipaměti (dost hemoragické, opět ve Wordpressu ), nebo při přechodu na jiný motor.

Vyzkoušel jsem většinu hotových blogových enginů v národních prostředích a došel jsem ke zklamání:
žádný z nich (!), dokonce ani s importem z wordpressu, nemohl poskytnout stejnou CNC strukturu (a ještě více v automatickém, intuitivním režimu), což znamená, že při přechodu na -> 301 přesměruje a není jasné, jaký druh reakce od PS z hlediska stávajících pozic.

Nakonec to dopadlo jako vždy: podíval jsem se na zdroje WordPressu, naimportoval data z existující databáze a napsal malou zdání CMS.

Zátěž: na MySQL klesla v průměru 10krát, na procentech 2krát. Zdá se mi, že z hlediska optimalizace je stále co zlepšovat, ale musíte uznat, že i toto je již orientační výsledek!

Závěr z tohoto příspěvku není vůbec takový, že by se měl každý hned vrhnout na psaní vlastních skriptů (alespoň myslet na ochranu proti hackingu), ale před instalací Wordpressu jako enginu blogu se párkrát zamyslet, protože pak to může být problematické změnit CNC a ještě více adresy stávajících odkazů (pokud samozřejmě nejsou zakoupeny).

15 komentářů

1. 1

   Dobré myšlenky, ale každý je má. Rád bych si přečetl možné řešení problémů s načítáním databáze změnou parametrů motoru

2. 2

   Hlavním směrem významné optimalizace WordPressu je ukládání do mezipaměti na straně serveru. Myslím, že si to můžete přečíst na mnoha jiných blozích. V současné době nemám jediný web postavený na Wordpressu, a proto nemohu popsat řešení problémů s optimalizací.

3. 3

   Na internetu vždy říkali, že VP je snadné, a já tomu věřil, i když ve svém životě používám Drupal. V září jsem pak dostal zákazníka s přáním „přejít z tohoto buggy VP na Drupal“. Ukázalo se následující:
   1. Stránka běžela na VPS 500Mhz a 384 snímcích
   2. Návštěvnost je asi 1000 návštěv za den.
   3. Všechny myslitelné a nepředstavitelné keše jsou zahrnuty.
   Celý tento systém neustále padal jednou denně a po zbytek času byl bezbožně pomalý. V důsledku toho začal drsný a pečlivý proces přechodu na Drupal:
   1. Všechny materiály byly znovu nataženy.
   2. Kde byly adresy URL uspořádány, nechali jsme je tam, kde nebyly uspořádány, vytvořili jsme nové adresy URL, 301 přesměrování na staré.
   3. Pohybovali jsme se absolutně bez ztrát. Se stejnou funkčností a na některých místech ještě více.
   Nyní zatížení procesoru serveru v nejtěžších okamžicích, kdy dorazí Gosha a Yasha, nepřesahuje 30 procent, s deaktivovaným ukládáním do mezipaměti.
   Takže přemýšlejte o Drupalu, není to tak špatné, jak všichni říkají.
   Zde je pacient - surlaterre.ru

4. 4

   Nemám nic proti Drupalu, je to dobrý systém. Moje hlavní stížnost je, že moderní motory nemají jednoduchý systém pro přechod z jiného CMS při zachování starého CNC systému.

5. 5

   Pokud vezmeme stejný přenos z VP, pak se stávající modul přenese spolu s adresami URL VP, ale přenesl jsem ho se svým modulem, všechno bylo pro mě trochu jiné

6. 6

   Jestli je ten či onen modul schopen přenést jakýkoliv typ adresy, kterou lze vytvořit pomocí standardních nástrojů Wordpressu, čest a chvála, +1 Drupalu, ale když jsem něco takového hledal mezi motory, nenašel jsem cokoliv, nebo jsem to našel, ale ne vše bylo implementováno.

7. 7

   Obecně mohu říci: „Není nic, co by nebylo přenosné“, pokud je téma zajímavé, pak vítejte na ICQ/mail/Skype. Kontakty na mém webu

8. 8

   Nevím, jak jste nakonfigurovali WordPress, server a mezipaměti. Ale mám weby běžící na WP, které mají na virtuálních strojích 4000 návštěvníků denně a bez problémů. Existují stránky s 10 000 návštěvníky na jedno zaklepání, ale v soukromí. Tam zatížení nepřesahuje ve špičkách 10 %. Takže WP je pořád rockový!

9. 9

   Momentálně se učím MovableType. Navzdory své neobvyklé povaze (používá perl a generuje statický html) je tento CMS velmi lehký a docela funkční. Mnohem rychlejší než WP.

10. 10

    MovableType je dobrý, ale v ruštině je o něm stále málo informací.

11. 11

    Osobně nemohu přijít na to, jaký druh zátěže tam je. Nikdy jsem neměl žádné velké WP projekty a nemohu to sám zkontrolovat. A bez ohledu na to, kde čtu, nic nepochopíte: někteří říkají pravidla wp, jiní říkají, že motor je svinstvo. Obecně jsem nikde neviděl, jakou zátěž a jaké wp vydrží. Zůstává jedna otázka: proč je potom wp v zóně ru na předních pozicích, možná kvůli své jednoduchosti?

Ahoj, ahoj. Často se blogeři a webmasteři potýkají s takovým problémem, že se jejich projekty dříve nebo později začnou strašně zpomalovat. Zátěž hostitelského CPU se výrazně zvyšuje a tradiční metody s řešením vůbec nepomáhají. A dnes bych vám rád řekl, co dělat, když je váš web WordPress pomalý a jak v tomto případě snížit zatížení serveru.

Ve většině případů výrazné zamrznutí a zpomalení na webu začínají zcela nečekaně, a proto zákonitě začíná panika. Ve stavu strachu si blogeři začnou „vybírat“ své stránky a snaží se je zachránit před tímto nepříjemným problémem. Ale častěji než ne, taková „záchrana“ končí neúspěchem, až po demolici místa bez možnosti obnovy.

To je ve skutečnosti velmi politováníhodné, zvláště pokud je blog starší než jeden rok a nashromáždil spoustu zajímavých a užitečných článků a čísla počítadel návštěv jsou každým dnem příjemnější. Nechtěl byste se dostat do tak hrozné situace? Pak máte velké štěstí, rád bych vás hned teď ochránil před špatnými věcmi a naučil vás, co dělat, když WordPress zamrzne.

Zrovna před pár dny mě kontaktoval jeden blogger a obchodník s informacemi, kterého mnozí velmi dobře znají - Dmitrij Zverev, s žádostí, aby viděl na svém blogu kruté mrazy. Přirozeně souhlasím, je to moje práce, hlavně proč nepomáhat dobrému člověku? 🙂

Takže Dmitry mi poslal všechna data z webu a hostingu a začal jsem je analyzovat. Představte si, že průměrná rychlost načítání webu byla až 13 sekund.

Těžké, že? Co mohu říci, kromě takové „rychlosti“ byla dostupnost stránky chabá, někdy se stránka otevřela pokaždé. Jedním slovem katastrofálně havaroval a odmítl plně fungovat. A nejzajímavější na tom bylo, že při přihlášení do administračního panelu byly problémy ještě větší!

To ve mně vzbudilo ještě větší zájem, protože jsem se s něčím takovým ještě nesetkal! "No, zkusme to, čím těžší, tím zajímavější," pomyslel jsem si a dal se do práce.

Nejprve jsem začal analyzovat aktivované a zjistit, které z nich zatěžují web nejvíce. Provedl jsem analýzu pomocí pluginu s názvem P3. Pokud má někdo zájem dozvědět se o něm více, přihlaste se k odběru aktualizací blogu. Určitě o tom napíšu v některém z následujících článků.

Tak jsem objevil 2 pluginy, které zatěžovaly blog více než ostatní: LeadPages a NextGEN Gallery. Ale po jejich vypnutí a vymazání mezipaměti se absolutně nic nezměnilo. A pak začala zábava. Začal jsem kopat hlouběji a hlouběji, abych našel pravou příčinu této ostudy :)

Po nějakém experimentování a testování jsem došel k závěru, že problém může způsobovat hosting. Psal jsem na podporu Jino, ale nikdy jsem nedostal jasnou odpověď ani pomoc. Mohl jsem se proto spolehnout pouze na sebe a své dlouholeté zkušenosti.

A nyní, po dvou dnech a mnoha pokusech, včetně naprosto zbytečných, se rychlost změnila takto:

A kromě toho přestaly neustálé poruchy a hostitelé si přestali stěžovat na zvýšenou zátěž CPU. Hurá! O co jsem usiloval, to se mi splnilo - mise splněna.

Co jsem ale přesně udělal a jak se mi podařilo vyhrát? Jdeme popořadě.

Snížení zátěže serveru

1. Nejprve vám doporučuji přečíst si jeden z mých prvních článků o zvýšení rychlosti načítání webu pomocí . V tomto článku se dozvíte, jak provádět vysoce kvalitní optimalizace webu a jeho efektivní akcelerace pro plnou práci. V tomto článku také demonstruji nejlepší služby pro kontrolu rychlosti.

Někdy však tyto tipy nestačí, například jako v případě Dmitrije. Po dokončení všech urychlovacích kroků z onoho článku se stránka začala otevírat ještě hůř a hostitelé na ni začali doslova blokovat přístup kvůli značnému přetížení. Proto bylo nutné provést některé další úkony.

2. Brzdy se často objevují kvůli skript s názvem WP-Cron. Tento skript zabudovaný do WordPressu je zodpovědný za plánování úloh. Například zveřejňování článků podle času, automatické čištění koše, vytváření zálohy pomocí pluginu atd.

Všechno se zdá být v pořádku, věc je v pohodě a tak, ale faktem je, že Cron vytváří velmi velké zatížení a někdy hostingové služby takové zatížení nevydrží a zablokují přístup na web. V takovém případě musíte tento skript zakázat a zatížení se výrazně sníží.

Měli byste však pochopit, že akce, které provádíte automaticky, již nebudou fungovat, budete je muset provádět ručně. Na tom ale není absolutně nic složitého.

Existuje tedy několik způsobů, jak zakázat WP-Cron. Faktem je, že některé z nich (jako tomu bylo v mém případě) nemusí fungovat, ale jiné ano.

1 způsob. Přejděte do kořenového adresáře svého webu přes Ftp, například přes FileZilla, a otevřete tam soubor s názvem wp-config.php a přidat nový řádek:

Define('DISABLE_WP_CRON', true);

Je vhodné jej přidat za řádek:

Define('WPLANG', 'ru_RU');

Pak soubor uložte a radujte se, skript by měl být deaktivován.

Ale pokud se tak nestane, musíte použít následující možnosti.

Metoda 2. Opět v kořenovém adresáři webu musíte otevřít soubor s názvem wp-cron.php, najdi řádek:

Ignore_user_abort(true);

a okomentujte jej (zakažte) pomocí dvou lomítek. Výstup by měl vypadat takto:

//ignore_user_abort(true);

Soubor uložíme a cron je deaktivován.

3. Dále potřebujete povolit kompresi zlib, který umožňuje výrazně zrychlit vaše stránky zpracováním a kompresí PHP kódu. V první řadě je potřeba napsat na hoster a zjistit, zda máte zapnutou funkci zlib či nikoliv. Pokud je připojen, skvělé, ale pokud ne, zapněte jej. Poté přejděte do souboru header.php a do samý vrchol vložte následující kód:

Uložíme soubor a cítíme výrazné zvýšení rychlosti.

4. Poté je to velmi důležité optimalizovat databázi pomocí pluginu. Přejděte na panel správce, otevřete kartu „Pluginy“ - „Přidat plugin“ a do vyhledávání zadejte „WP-Optimize“, stiskněte Enter a nainstalujte první plugin.

Nyní je naše databáze optimalizována a to je další plus ve směru zrychlení webu.

5. Nyní náš úkol chránit svůj blog před útoky Ddos, protože Právě takové útoky se často stávají důvodem k „rozbití mozku“ webu. K tomu zaprvé doporučuji nainstalovat plugin s názvem iThemes Security, o jeho nastavení budu mluvit v příštím článku a zadruhé je důležité využít blokování podezřelých návštěvníků pomocí .htaccess.

Nebudu nyní vysvětlovat, jak takové podezřelé a škodlivé hledat, protože toto je téma na samostatný článek, ale podělím se s vámi o seznam IP adres, které se mi za nějakou dobu podařilo nasbírat. Právě oni budou muset být zablokováni.

Pravděpodobně začneme optimalizovat Pojďme!

Příklad nadměrného zatížení serveru.

Řekněme, že uživatel navštíví web, ale co se stane, když se stránka otevře? Jak se informace zobrazují na obrazovce? Podívejme se na tento proces na příkladu záhlaví webu.

Titulek a URL hlavní stránky webu, pokud si pamatujete, se nastavuje v nastavení WordPressu: admin -> Možnosti -> Obecné. Všechna nastavení dostupná v záložce „Options“ se zadávají do databáze, přesněji do tabulky wp-options, odkud jsou následně různými funkcemi vyžádána a zobrazena na obrazovce.

Vývojáři WordPres napsali poměrně dost funkcí, ale nelze je provádět samostatně. Pro jejich plnohodnotnou práci je nutný určitý spojovací článek, jehož úlohou je šablona webu.

Šablona, ​​jak víte, se skládá z několika souborů, z nichž každý je zodpovědný za zobrazení konkrétní části webu. Nás teď zajímá hlavička, kde je zobrazen nadpis, takže otevřeme soubor header.php a podíváme se, co je tam napsáno.

Ve většině šablon je hlavní název webu uzavřen ve značce h1, takže hledáme sekci kódu s touto značkou. V mé šabloně vypadal výstupní kód záhlaví takto:

/">

Skvělé, nadpis by měl být odkaz, takže kód obsahuje konstrukci kotva . Ale co je to napsané místo odkazu? A kotva je nějaká zvláštní. Ale to je jasný příklad nadměrného zatížení serveru.

Kotvem se budeme věnovat o něco později, ale nyní se pojďme seznámit s funkcí get_option().

get_option() funkce a zatížení serveru

Zadali jsme tedy název a URL hlavní stránky webu do nastavení WordPress a byly uloženy v databázi, v tabulce wp-options.

V okamžiku, kdy uživatel otevře libovolnou stránku našeho zdroje a soubor header.php začne načítat hlavičku, aktivuje se funkce get_option().

Principem fungování výše zmíněné funkce je přistoupit k databázi, respektive tabulce wp-options a na základě zadaných parametrů odtud získat určitá data. Poté tým echo zobrazí přijatá data na obrazovce.

Je to trochu složité, ale to nevadí, teď vše vysvětlím. V závorkách je uveden parametr, v našem případě get_option('home') , který funkci říká, jaký typ dat potřebuje přijímat.

Parametr home dává funkci pokyn, aby si vyžádala URL domovské stránky z databáze. Zastávka! Takže adresa URL domovské stránky je také uložena v databázi? Právo. A když je stránka otevřena, funkce si to vyžádá, to znamená, že přistupuje k datům uloženým na serveru.

Nyní si představte, že na váš zdroj přišlo 100 návštěvníků a začali si hrát a otevírat další a další stránky.

Pravděpodobně jste slyšeli o útocích hackerů na různé stránky, během nichž tisíce nebo dokonce miliony požadavků zasáhly server současně, což způsobilo selhání serveru a zablokování zdroje.

Musíme pochopit, že pokud snížíme počet požadavků na databázi, umožníme serveru volněji „dýchat“ a uvolněné zdroje využije na užitečnější věci, což se samozřejmě projeví na rychlosti načítání stránek.

Vraťme se k funkci get_option(). Pro získání určitých dat z databáze může funkce přijmout následující parametry:

get_option("home") – URL domovské stránky
get_option("admin_email") — E-mail správce webu;
get_option("blogname") — Název webu;
get_option("blogdescription") — Stručný popis webu;
get_option("blog_charset") — Kódování webu;
get_option("date_format") — Formát data;
get_option("default_category") — Výchozí kategorie;
get_option("siteurl") - WordPress URL (viz Možnosti -> Obecné);
get_option("start_of_week") - První den v týdnu;
get_option("cesta k načtení") - Výchozí adresář pro nahrávání (zastaralé);
get_option("posts_per_page") - maximální počet příspěvků na stránku;
get_option("posts_per_rss") — Maximální počet příspěvků ve zdroji RSS;

Většina uvedených datových typů je specifikována v nastavení WordPress na záložce „Možnosti“. Výjimky jsou: „Kódování webu“ – indikováno přímo v databázi a „Výchozí adresář pro stahování“ – volba byla od verze 3.5 odstraněna z nastavení.

Proč to všechno říkám? Faktem je, že obsah souborů v šabloně je pro každého jiný, ale pokud pochopíte, co se v nich píše a jak to funguje, bude mnohem jednodušší WordPress optimalizovat a zbavit se zbytečných volání do databáze.

Jak a čím nahradit funkci get_option() vám řeknu o něco později, ale nyní zjistíme, jaký druh bloginfo() je napsán v kódu místo kotvy.

funkce bloginfo() a zatížení serveru

Vraťme se do okamžiku, kdy uživatel stránku otevřel. Zjistili jsme, že URL domovské stránky bylo převzato z databáze pomocí funkce get_option('home').

Dobře, kde se tedy vzal samotný název? Titul je také uložen v databázi, ale v našem případě byl přijat a zobrazen jinou funkcí - bloginfo().

Poznámka! bloginfo() je značka šablony, která umožňuje funkci get_bloginfo(). Lze použít kdekoli v šabloně.

Funkce bloginfo() může přijímat následující parametry:

bloginfo("url") — Zobrazí adresu URL webu;
bloginfo("name") - Zobrazí název webu;
bloginfo("popis") - Zobrazí popis webu;
bloginfo("template_url") - cesta k aktuálnímu adresáři motivu;
bloginfo("adresář_šablony") - stejné jako "url_šablony";
bloginfo("stylesheet_url") - cesta k šabloně stylů aktuálního tématu;
bloginfo("stylesheet_directory") - stejné jako "stylesheet_url";
bloginfo("charset") — Zobrazuje kódování webu;
bloginfo("admin_email") — Zobrazí e-mailovou adresu správce;
bloginfo("verze") – Zobrazuje verzi WordPressu;
bloginfo("html_type") - Výstupy dat z html_type tabulky wp-options;
bloginfo("pingback_url") - cesta k souboru xmlrpc.php;
bloginfo("rss2_url") — Zobrazí adresu URL zdroje RSS 2.0 (doména/zdroj);
bloginfo("comments_rss2_url") — Zobrazí adresu URL zdroje komentářů (doména/komentáře/zdroj);
bloginfo("rdf_url") — Zobrazí adresu URL zdroje RDF-RSS 1.0 (doména/zdroj/rfd);
bloginfo("rss_url") — Zobrazí adresu URL zdroje RSS 0.92 (doména/zdroj/rss);
bloginfo("atom_url") — Zobrazí adresu URL zdroje Atom (doména/zdroj/atom);

Funkce bloginfo() je mírně odlišná od funkce get_option(), ale funguje na podobném principu, tedy vyžaduje určitá data z databáze a zobrazuje je na obrazovce.

Stojí za zmínku, že existují různé názory na zatížení na severu vytvořené funkcí bloginfo(). Zátěž ale rozhodně existuje, a pokud je možnost ji snížit, pak by byl hřích této příležitosti nevyužít.

Udělal jsem celou řadu opatření, po kterých se můj blog zrychlil více než dvakrát rychleji.

Navíc nepoužívám žádné cache pluginy ani skripty jako MaxCache a také jsem neměnil hosting a zůstal věrný TimeWebu. Výsledek byl dosažen pouze díky optimalizaci WordPressu. Udělejte si tedy vlastní závěry.

Samozřejmě, že opatření, která jsem přijal, se netýkají pouze redukce dotazů do databáze a postupně vám vše řeknu, ale nemohu tento objemný materiál nacpat do jednoho článku.

Očekávejte tedy nové novinky věnované rychlosti načítání stránek, a abyste je nepropásli, přihlaste se k odběru aktualizace blogu.

Technologie redukce dotazů databáze

Dovolte mi připomenout, jak vypadá kód záhlaví v mém souboru header.php:

/">

Nyní přichází ta zajímavá část. Pokud se podíváte na zdrojový kód, kód záhlaví tam bude mít úplně jinou podobu:

Toto je kód záhlaví, který by měl být zapsán do souboru header.php. Poté se server zbaví dvou zcela zbytečných požadavků, vynásobených počtem otevřených stránek.

Ale proč jsou pak výše zmíněné funkce zapsány v souborech šablon?

Vývojáři totiž nemohou vědět, na jaké doméně budou následně použity jimi vytvořené šablony a také nemohou vědět, jaké názvy budou mít stránky. Proto byly vyvinuty univerzální funkce pro všechny šablony, které přijímají data z databáze.

Ale vy i já známe název našeho webu a známe i doménu. Ukazuje se, že není potřeba tyto funkce používat.

Počínaje souborem header.php proto hledáme sekce kódu s výše uvedenými funkcemi, pak se podíváme, jak vypadají ve zdrojovém kódu a nahradíme je.

Pro posílení materiálu uvedu několik příkladů. Zde je kód, který zobrazuje informace o kódování.

; znaková sada=" />

Podívejme se na zdrojový kód:

Zkopírujeme celý řádek a vložíme jej místo kódu s funkcemi.

Kód pro připojení souboru style.css:

" type="text/css" media="screen" />

Cesta k šabloně stylů je odvozena pomocí funkce bloginfo('stylesheet_url'). Podívejme se na zdrojový kód:

/images/fav.ico" type="image/x-icon" />