Optimalizace rychlosti webových stránek je nikdy nekončící boj. Jakmile dosáhnete uspokojivého stavu a zaměříte se na další zvyšování návštěvnosti, velmi brzy budete rychlost webu řešit znovu. Ať už investicí do jiného hostingu nebo do vlastního serveru s vyšším výkonem.
Faktem je, že při provozu webu na sdíleném webhostingu nemáte moc možností, jak rychlost webu ovlivnit. Tedy kromě úprav na webu samotném. Zapomeňme tedy v tuto chvíli na externí cache a zrychlovače typu memcached, nginx, Varnish či APC. Podívejme se, jak můžete pomoci načítání webu s redakčním systémem Drupal úpravou jeho nastavení.
1. Klasický základ – optimalizace CSS, JS a obrázků, zapnutí cache
Aby nedošlo k mýlce, nebudu vám tu psát, jak používat Firebug či jiné nástroje pro měření rychlosti webu. Ty najdete v jiných článcích. O tom, že je vhodné používat co nejmenší obrázky jak v CSS, tak přímo v obsahu stránek, o tom žádná. S jejich optimalizací vám pomůže například Smush.it od Yahoo.
Pokud můžete, nepoužívejte externí JavaScript. Dosti často se stává, že zdrojový server má nějaký problém a vaše stránka se kvůli tomu tváří, jako by se neustále načítala – čeká právě na ten externí soubor.
Na rychlost načtení webu má vliv samozřejmě velikost přenášených dat. V Drupalu lze agregovat/komprimovat všechny CSS a JavaScripty, jsou-li použité moduly a témata vzhledu správně udělány. Nastavení najdete v administrační části Konfigurace > Vývoj > Výkon. Navíc tu lze zapnout komprimaci stránek v mezipaměti a cache.
Drupal při zapnutém cacheování ukládá vygenerovanou HTML strukturu pro jednotlivé stránky do speciální tabulky v databázi. Pokud se taková stránka opětovně posílá k nějakému uživateli, nemusí složitě z dalších údajů v databázi zjišťovat nové články, komentáře, příspěvky a další obsah, ale prostě si vezme již vytvořené HTML a uživateli jej zobrazí. Po jaké době má Drupal takto připravený HTML výstup aktualizovat, určíte pomocí rozbalovacích nabídek s intervaly.
Dlužno dodat, že výchozí cache Drupalu se týká jen nepřihlášených uživatelů, pro přihlášené se neuplatňuje. Navíc jakékoli cacheování na straně Drupalu má nevýhodu v tom, že stránka nemusí vždy zobrazovat nejaktuálnější informace. Například při nastavení minimální životnosti cache na 5 minut se nepřihlášeným uživatelům objeví nový článek na titulce webu nejpozději až pět minut po jeho vydání (záleží na tom, kdy byla cache naposledy aktualizována).
V případě, že máte pomalou databázi, můžete zkusit alternativní moduly umožňující vyváření cache na stejném principu, ale do podoby souborů. Po instalaci modulu Boost budou připravené HTML struktury ukládány do podoby souborů a odtud servírovány návštěvníkům webu. Nastavení tohoto modulu však není triviální a pokud si dobře pamatuji, v době Drupalu 6 jsem u něj narazil na spoustu problémů. Doba však pokročila, takže směle modul vyzkoušejte, chcete-li.
2. Nepoužívejte Views UI
Pokud byste někdy svůj web připojili na službu Acquia Network, mezi mnoha doporučeními uvidíte též tip na vypnutí modulu Views UI. V případě, že máte uživatelské rozhraní pro nastavení Views zapnuto, může docházet k menšímu zpomalení rychlosti stránek. Abych pravdu řekl, okem jsem to nikdy nepostřehl, ale logika věci říká, že je to pravda.
Samotné vypnutí modulu Views UI nemá vliv na fungování jednotlivých Views, které jste si na webu nastavili. Hotové pohledy budou samozřejmě dále funkční, protože Views samotné nevypnete, pouze jejich ovládání – Views UI.
Někteří vývojáři navíc Views úplně obcházejí a dávají přednost tomu, že si jednotlivé výpisy naprogramují ve vlastních modulech. Někdy to může být ku prospěchu věci a výsledný SQL dotaz v modulu šitém na míru je na databázi méně náročnější, jindy zase není zbytí a některé výpisy pomocí Views prostě nenastavíte. Obecně bych se ale použití Views v rozumné míře a při zapnutém cacheování nebál.
3. Cacheování Views
Pokud modul Views používáte a máte zapnuté cacheování webu, zvažte ještě nastavení cache v jednotlivých pohledech tvořených modulem Views. Zatímco hlavní cache Drupalu ukládá již vytvořenou HTML strukturu, cache ve Views si uchovává výsledek SQL dotazů, které provádí pro získání dat pro jednotlivé výpisy.
Z toho plyne, že cache ve Views je nezávislá na hlavní cache Drupalu. I když nebudete z nějakých důvodů hlavní cache Drupalu používat (třeba kvůli přepínání vzhledu webu), může vám cacheování výpisů ve Views náročnost požadavků na databázi snížit.
Cache pro jednotlivé pohledy nastavíte v jejich editaci. Rozklepněte si položku Pokročilé a u položky Mezipaměť klikněte na odkaz Žádné. V dialogu zvolte volbu Time-based a v dalším kroku pak nastavte, po jaké době se bude aktualizovat množina dat získaných z databáze a po jaké době se aktualizuje HTML struktura sestavená na základě těchto dat. Z toho samozřejmě vyplývá, že pokud nastavíte hodinový interval a máte na webu výpis posledních příspěvků, tak nový příspěvek se v něm může objevit třeba až za hodinu.
4. Potřebujete ve Views duplicitně kontrolovat oprávnění pro přístup k obsahu?
Jedno z pokročilých nastavení ve Views může zrychlit jejich zpracování až o sekundy, v případě opravdu velkého webu s množstvím záznamů v databázi. Neznalost tohoto nastavení také vede řadu vývojářů k tomu, že si raději výpis napíší ve vlastním modulu, než by jej připravili pomocí Views.
Všechny výpisy tvořené modulem Views totiž při získávání třeba seznamu uzlů kontrolují, zda k nim má uživatel přístup a může je vidět. Abych byl úplně konkrétní. Řekněme, že na webu pomocí Views zobrazujete nejnovější vydané články. Vydaný obsah může vidět jakýkoli uživatel. Ve Views proto do filtrů přidáte podmínku, že chcete zobrazovat jen ten obsah, který má příznak Vydáno nastaven na Ano. Je potřeba nějaká další kontrola?
Ve většině případů toto omezení bohatě stačí, málokterý web ještě kontroluje, zda k jednotlivým článkům, přestože jsou vydány, může uživatel přistupovat nebo ne (ale jsou takové weby). Views však vždy tuto kontrolu přidávají a tím výrazně navyšují náročnost dotazu do databáze. Naštěstí se lze této jejich vlastnosti zbavit. V editaci pohledu si rozklepněte sekci Pokročilé a klepněte na Nastavení u Query settings. Zapněte zde volbu Disable SQL Rewriting a nastavení uložte.
Sami si můžete vyzkoušet, jak se tato úprava projeví na rychlosti získání dat z databáze. V Struktura > Views > Nastavení si zapněte volbu Show the SQL query. Ta vám při editaci jednotlivých pohledů a generování náhledu ukáže sestavený SQL dotaz. Zkopírujte si jej třeba do phpMyAdmina a zkuste spustit. Poté Views upravte výše popsaným způsobem, kdy vypnete onu kontrolu přístupu k obsahu a zkuste v phpMyAdminovi spustit nově vytvořený SQL dotaz. PhpMyAdmin zobrazuje délku zpracování dotazů a ta by měla být podle velikosti vašeho webu velmi odlišná ve prospěch zde popisované úpravy (kdyžtak napište do komentářů zjištěné výsledky).
Poznámka: Některé moduly mohou SQL dotazy generované na pozadí modulem Views přepisovat a pokud SQL Rewriting vypnete, přestanou výpisy správně fungovat. Ale opět, je to jen výjimečná situace. Samozřejmě při této úpravě hrozí i riziko, že se uživatel dostane k obsahu, který nemá vidět. Nesmíte tedy při vypnutém SQL Rewritingu zapomenout správně nastavit filtry ve Views, třeba jen pro zobrazení vydaného obsahu.
5. Jak dlouho běží cron?
Pokud vám někdy provozovatel hostingu napíše, že váš web jej čas od času výrazně zatěžuje, aniž by byla nějak zvýšená návštěvnost, může být jednou z příčin nějaký problém při naplánovaných operacích, o které se v Drupalu stará cron. Bohužel Drupal sám o sobě neumí žádné podrobné informace o průběhu běhu cronu zobrazit. Naštěstí je tu modul Elysia Cron, který vám vše potřebné sdělí a navíc umožní detailnější rozplánování na pozadí spouštěných procesů.
6. Nepoužívejte zbytečné moduly
Říkám na to neustále, na kurzech v GOPASu i jinde. Nepoužívejte zbytečné moduly. Pokud například víte, že na webu nikdy nebudete zobrazovat RSS feedy z externích zdrojů, je zbytečné mít zapnutý modul Aggregator. Pokud jste schopni pracovat se šablonami a CSS, nepoužívejte modul Panels. Vykašlete se na tisíce modulů dělajících jedno a totéž.
Každý modul, který je v Drupalu zapnutý, znamená, že při načítání stránky jej Drupal musí projít, podívat se, na které procesy je modul napojený a případně jeho funkce zpracovat. Při stavbě webu si tedy zkoušejte a hrajte s moduly dle libosti, ve finále ale ty nepotřebné nezapomeňte vypnout a hlavně odinstalovat. Tím se zbavíte i změn v databázi, které tyto moduly provedly. Ze souborové struktury webu nepotřebné moduly smažte teprve až po jejich odinstalování.
7. Optimalizujte databázi
Tak, jak web postupně roste, přidávají se a odebírají z databáze různé záznamy. Pokud to připodobním k fragmentaci pevného disku, i v databázi tak mohou vznikat hluchá místa, která tam zbývají po odstraněných záznamech. Udržovat databázi v kondici vám pomůže modul DB Maintenance.
8. Pozor na velký počet komentářů a tagů
Na konec jsem si nechal poznámku, ze které sice nevyčtete žádný tip na optimalizaci rychlosti webu, ale je dobré s touto situací nějak počítat. U velkých webů často neúměrně roste počet komentářů a tagů. Jestliže jdou tyto záznamy do desítek či stovek tisíc, může se web zásadním způsobem zpomalit. V takovém případě se vyvarujte zbytečných boxíků s výpisem posledních komentářů a pokud je potřebujete, sestavte je pomocí Views a nastavte jim cache s delší časovou prodlevou. Nezapomeňte též na hlavní cache Drupalu.
Co se tagů týče, tam může být problém podobný a troufám si tvrdit, že často se jejich počet vyšplhá mnohem výše, než počet komentářů na webu. Používejte je tedy s mírou, neumožňujte jejich přidávání třeba ve fóru a občas si je projděte a sjednoťte. Třeba s moduly Term merge a Taxonomy Manager.
Tvůrce webů z Brna se specializací na Drupal, WordPress a Symfony. Acquia Certified Developer & Site Builder. Autor několika knih o Drupalu.
Web Development Director v Lesensky.cz. Ve volných chvílích podnikám výlety na souši i po vodě. Více se dozvíte na polzer.cz a mém LinkedIn profilu.
Podobné články
Komentáře k článku
Bezva. Ještě mě tak napadlo k bodu 3 a překladům. Zvlášť důležité je toto pravidlo v momentě, kdy zapnete podporu překladu i pro textový formát Full HTML. Tabulka s překlady pak nebude hodně velkých objemů. Jinak ty další údaje by se měly odstranit - za předpokladu, že je modul správně napsaný a obsahuje proceduru, která po něm při odinstalování uklidí.
OK,a ešte som zabudol doplniť k bodu "2. Nepoužívejte Views UI" v článku, platí aj pre ostatné UI a vývojárske moduly(napr. Rules UI, Field UI, ale aj Localization update, Devel a pod...). komplexne sa to dá riešiť ak používate admin_menu po povolení sub-modulu "Administration Development tools", ale na to pozor, pretože sa vypínajú aj závislé moduly a to niekedy nechceme:-)
Ďakujem za zhrnutie, ak môžem doplním o "svoje" znalosti.