Drupal SEO modulok előadás

UPDATE: Az előadást elhalasztottuk, részletek lent. Bocsi, rajtam nem múlt a dolog.

UPDATE 2: Végül meg lett tartva az előadás. A bemutatott keresőoptimalizálás moduloknak pedig készítettem egy külön oldalt: Drupal SEO modulok.

Most csütörtökön, a Budapesti Drupal felhasználói találkozón (ismertebb nevén DUG) előadást fogok tartani „Drupal SEO modulok” témában. Lesz majd hivatalos bejelentés drupal.hu-n helyszínnel és időponttal, itt most csak a témát vázolnám röviden:

  • Rövid bevezetés a keresőoptimalizálásba
  • Általános megfontolások, amit minden weboldalnak figyelembe kellene venni
  • Drupal keresőoptimalizálás modulok ismertetése csoportokra bontva: URL menedzsment, Meta adatok, integráció, tartalom ajánlás, megosztás, stb...
  • Egy apró módosítás a Drupal magon
  • A saját fejlesztésű Google Rankings modul bemutatása. A készülő modul statisztikát ad a Google találati oldalakon a helyezésünkről, anélkül, hogy a Google szervereit lekérdeznénk, vagy bármely külső adatot használnánk.

Gyertek, jó lesz.

Már .CO domaineket is lehet regisztrálni.

.CO ccTLD logo Mindössze néhány órával ezelőtt teljesen felszabadultak a .CO domainek, most már bárki regisztrálhat magának ilyen domaint. Ez a lehetőség, többek között, azoknak jöhet jól, akik lecsúsztak a .COM-ról, hiszen eléggé hasonlít hozzá.

A .CO egy ccTLD azaz egy un. country code top level domain, Kulumbia TLD-je, úgy mint Magyarországnak a .HU

A GoDaddy-nél $29.99-ba kerül egy domain, vagy $24.99 nagy mennyiségű regisztráció esetén. Máshol láttam olcsóbban is, de nem tűnt elég megbízhatónak a cég.

A teszt véget ért, a GoDaddy linket kivettem. A teszt eredménye: egyetlen egy vásárlás sem történt.

Subversion adattár böngésző WebSVN-nel és Drupal szintaxis kiemeléssel.

Drupal szintaxis kiemelés WebSVN alattBár a Drupal projekt CVS-ről GIT-re vált, azért még így is elég sokan vagyunk, akik verziókezelésre Subversiont használunk, a Drupal közösségen belül és kívül egyaránt.

Egy verziókezelő használata során nekem mindig szükségem volt valamilyen eszközre, amely vizuálisan ábrázolja a különböző verziók, branch-ek közötti eltéréseket, vagy egyszerűen csak böngészni lehet vele a verziókezelőben tárolt adatokat, azaz a repository-t.

A WebSVN egy jól bevált Subversion böngésző, amelyet most Drupal szintaxis kiegészítéssel fogunk fűszerezni.

Hozzávalók

Elkészítés

Bizonyosodjunk meg róla, hogy a telepített subversion szerver és a http szerver (pl. Apache) működik.

Töltsük le a subversion verzióhoz megfelelő WebSVN verziót. 1.4-es SVN felett már használható a legfrissebb, 2.3-as WebSVN. A subversion verziószámát így deríthetjük ki:

# svnadmin --version

WebSVN telepítés

A WebSVN telepítése gyerekjáték. Csomagoljuk ki a letöltött fájlt egy könyvtárba, ahonnan a webszerver majd ki fogja szolgálni. Majd kövessük a doc/install.html utasításait. Ez mindössze annyit fog jelenteni, hogy az include/distconfig.php fájlt le kell másolnunk include/config.php néven, majd ezt a fájl értelemszerűen szerkesztenünk kell.

A config.php fájlban meg kell mutatni a WebSVN-nek, hogy hol találja az svn repositorykat. Ehhez a $config->addRepository() vagy a $config->parentPath() megfelelő beállítása szükséges. A beállításhoz minden szükséges információ rendelkezésre áll a config.php fájlban megjegyzés formájában.

A WebSVN a repositorykat az svn és az svnlook parancsok segítségével fogja olvasni, úgyhogy ezek elérhetőek kell legyenek a path-ban webszerver felhasználó számára. Ha mégsem, akkor a config fájlban a parancsok pontos helye is beállítható.

A WebSVN futtatásához nem szükséges adatbázis. Ha eddig mindent jól csináltunk, akkor van egy működő WebSVN-ünk, próbáljuk ki!

Drupal syntax highlight

Az utolsó lépés a legérdekesebb, Drupal szintaxis kiemelőt fogunk beállítani a WebSVN-hez. Ehhez a Drupal GeSHi filter modulból fogjuk kölcsönvenni azt a fájlt, amelyik a Drupal függvények és konstansok definícióját tartalmazza.

Töltsük le és csomagoljuk ki a Drupal GeSHi filter modult. Mindegy hova, most épp nincs szükség telepített Drupal-ra. Keressük meg a geshifilter/geshi-extra/drupal6.php nevű fájlt (ha drupal 5 szintaxis kiegészítést szeretnénk, akkor a drupal5.php fájlt használjuk) és másoljuk át a fájlt a már telepített WebSVN lib/gheshi nevű könyvtárába. Ebben a könyvtárban vannak a programozási nyelvek leírói. Itt fogjuk megtalálni a perl.php-t, a php.php és 156 másik nyelv leíróját.

Legutolsó lépésként már csak azt kell elmagyarázni a WebSVN-nek, hogy mely fájlok esetén szeretnénk drupal szintaxis kiemelést látni. Ehhez nyissuk meg újra az include/config.php fájlt és bizonyosodjunk meg arról, hogy a $config->useGeshi() parancs nincs megjegyzésbe téve. Illetve szúrjuk be még ezt a sort:

<?php
$extGeshi
['drupal6'] = array('module','inc','install','profile','test');
?>

Ezzel elértük, hogy a module, inc, stb. kiterjesztésű fájlokat a drupal 6 nyelvűnek értelmezi a WebSVN és ennek megfelelő szintaxis kiemelést alkalmaz majd.

Ha mindent jól csináltunk, és megjelenítjük például egy drupal modul forráskódját (*.module) a WebSVN-ben, akkor a Drupal mag függvényei és konstansai kiemelten jelennek meg és link-ként viselkednek, amelyek az api.drupal.org-ra mutatnak. Emellett természetesen megmarad a PHP szintaxis kiemelés is, amely linkek viszont a php.net-re mutatnak.

A bejegyzés megírásához ezeket a verziókat használtam:
Subversion: 1.6.6 (r40053)
WebSVN: 2.3.1
GeSHi filter: 6.x-1.3

Az eredeti receptre Wim Leers blogján akadtam rá: http://wimleers.com/article/run-your...drupal-syntax-highlighting, köszönet érte!

Boost modul: a Drupal esete a statikus html oldalakkal.

A múlt heti bejegyzésben arról írtam, hogy egy gyors weboldal miért jelent versenyelőnyt a konkurenciával szemben. Kétféle sebesség probléma lehet, a kliens oldalon akkor van gond, ha a böngésző program nehezen vagy lassan jeleníti meg az oldalt. Szerver oldalon pedig akkor van gond, ha a böngészőnek indokolatlanul sokat kell várnia a szerverek válaszára.

A Drupal boost modul egy szerver oldali megoldás: az anonim felhasználók oldalletöltéseit teszi villámgyorssá.

Tisztán emlékszem a 2. Magyar PHP konferenciára, ott hallottam először a Drupalról. Abban az időben nagyon foglalkoztatott a weboldalak sebességének optimalizálása, azon belül is az előre legenerált statikus html oldalak kiszolgálásának voltam nagy rajongója. Fel is tettem a kérdést az előadónak, hogy a Drupal tud-e ilyet. Ha jól emlékszem, valami olyasmit válaszolt Goba, hogy az alap rendszer nem tudja, de biztosan készíthető hozzá ilyen modul.

Nos, hölgyeim és uraim, a Drupal boost modul egészen pontosan ezt csinálja: előre legyártott statikus html fájlokat szolgál ki az anonim felhasználóknak. Ezáltal teljes egészében kihagyva a buliból a PHP, Drupal, SQL stacket.

Ez a megoldás villámgyors oldal kiszolgálást eredményez, és egyben hatalmas tehertől szabadítja meg a webszervert. Persze vannak hátrányai is a megoldásnak, de előbb nézzük röviden hogyan működik.

A Boost modul működése

Először telepíteni kell magát a modult. Ez fog gondoskodni a statikus html fájlok mentéséről. Létre kell hozni egy „cache” nevű könyvtárat a Drupal telepítés gyökerében, ide fognak kerülni a html fájlok. Végül pedig a .htaccess fájlba be kell másolni egy nagy adag kódot, itt történik a varázslat: ez gondoskodik a html fájlok kiszolgálásáról.

A .htaccess fájlba másolt kód több különböző feltételt figyel, és ha mindegyik teljesül, akkor a Drupal index.php helyett az elmentett statikus fájl kerül kiszolgálásra. Ilyen feltétel például, hogy nem létezik a DRUPAL_UID nevű cookie, azaz hogy nem bejelentkezett felhasználó nézi az oldalt, vagy hogy GET kérésről beszélünk, és nem POST-ról.

Az eredmény: villámgyors oldal kiszolgálás az anonymous látogatók számára.

A cache fájlok érvénytelenítése

Ha egyszer elkészült egy oldalhoz egy statikus gyorstár fájl, és a fent említett feltételek teljesülnek, akkor az bizony ki lesz szolgálva. A kiszolgálás pillanatában ugyanis nincs lehetőségünk mérlegelni, hiszen nem fut le semmilyen Drupal vagy PHP kód. Éppen ezért alaposan oda kell figyelni, hogy mikor kerül érvénytelenítésre egy oldal gyorstár változata.

Először is, van egy beállítható felső idő határ. Ha ennél régebbi a cache fájl, akkor a boost törli az időzített feladatok (cron) segítségével.

Ha egy node oldalról beszélünk, akkor a node módosításakor is törli a cachet. Ha hozzászólás érkezett a node-hoz, szintén megy a cache a kukába. Ha egy node megkapja a „Promoted to front page”, azaz címlapra helyezés státuszt, akkor meg a kezdőlap lesz törölve. Persze ez csak a Drupal alapértelmezett kezdőlapjával működik. Ha saját kezdőlap megoldásunk van, és használni akarjuk a boost-ot, akkor nekünk kell gondoskodni a címlapi gyorstár törléséről.

A taxonómia lista oldalak fájljait is helyesen üríti a modul, amikor kell. Sőt elvileg CCK tartalomra hivatkozás mező használata esetén, ha változik a hivatkozás, akkor is helyesen törlődnek a megfelelő node gyorstárak.

Mindezeken felül persze lehet, hogy szükségünk lesz saját érvénytelenítő kódot is írni. Ha egyedi címlapot használunk, akkor mindenképpen.

Hátrányok

Az egyik hátránya a modulnak, hogy csak az Apache kiszolgálót támogatja teljes egészében. Márpedig maga az Apache is egy elég komoly lassító tényező, mint ahogy múlt héten egy hozzászólásban is írták. Elvileg nginx, lighthttpd és IIS7 használata is megoldható, többé kevésbé. Én ezeket nem próbáltam még.

A másik gond magából a módszerből adódik: mivel kikerüljük a Drupal-t, ezért az alaprendszerbe épített statisztika modul, illetve hasonló analitika megoldások egyáltalán nem fognak működni. Jelenleg egy nagyon izgalmas, saját fejlesztésű modulon dolgozom, amely azonban épít a Drupal mag statisztika megoldására. Ezért sajnos a kettő együtt nem működik.

Szintén a technológiából adódik, hogy a weboldal jobb és bal sávjaiban elhelyezett dobozok tartalma nem mindig frissül, és ezért Boost használata esetén néha furcsán inkonzisztens adatok jelennek meg. Illetve a véletlenszerűen változó dobozok, például 5 véletlenül kiválasztott fórum téma az elmúlt 1 hétből, sem úgy működik, mint ahogy kellene neki.

Mikor megnéztem a forráskódot, megdöbbenéssel tapasztaltam, hogy a Boost modul hatalmas! 280 KB-nál nagyobb a PHP kód mérete. Egyrészt azért ilyen nagy, mert sok kód kell az különböző cache fájl érvénytelenítési esetek kezelésére. Másrészt sok extra dolgot tud, talán feleslegesen is (lásd lent). És elég sok beállítási lehetősége is van. Egyszóval nagy és bonyolult modul, jobban örültem volna, valami egyszerű és nagyszerű megoldásnak.

Egyéb érdekességek

A Boost modul favorizálja a tömörített (gzip) kiszolgálást, méghozzá elég agresszíven. Állítólag némely proxy szerver felülírja a böngésző által küldött HTTP fejlécét, hogy ne fogadjob GZIP tömörített adatot. A modul egy trükkel (IFRAME-ben meghívott GZIP-pel tömörített oldalban lévő javascripttel beállít egy cookiet) megpróbálja kideríteni hogy az aktuális böngésző támogat-e gzip tömörítést, és ha igen, akkor az Accept-Encoding fejléctől függetlenül GZIP-el küldi az adatot.

Van egy beépített web robot is a Boost-ban. Annyit tesz, hogy cron futás alkalmával bejárja az oldalunkat (konfigurálható, hogy ezt hogyan tegye), ezzel előmelegítve a gyorstárat. Mikor van erre szükség? Ha olyan weblapot készítünk, amire várhatóan kevés oldalletöltés érkezik. Ekkor ugyanis a cache általában túl régi lesz, azaz a látogatók többnyire gyorstárazás nélküli oldallal találkoznak majd.

Konklúzió

Nagyszerű modul, ha az ember együtt tud élni a kötöttségekkel: Apache kiszolgáló, nem mindig frissülő dobozok és az anonim látogatói statisztika hiánya a Drupalban. Utóbbi miatt jelenleg én sajnos egyetlen oldalon sem használom. Persze ha egy szerverem nem bírná már a terhelést, akkor nyilván feltenném: inkább lássák a látogatók az oldalt és nekem ne legyen látogatottsági adatom, mint hogy ne is lássák :)

Gyors honlapokat akarok

Régi hitvallásom, hogy egy weboldal sebessége kritikus szempont. Mindig. Versenyelőnyhöz juthat az a cég, amelyik gyors weboldallal rendelkezik. Miért? Mert szívesebben kattintunk, ha tudjuk, hogy azonnal rendelkezésre fog állni az információ. Ha szívsebben kattintunk, gyakrabban is tesszük ezt, azaz több oldalletöltést hozunk létre böngészés közben. Viszont, ha várni kell egy oldal letöltődésére, akár csak néhány másodpercet, közben megnyithatnak egy új fület a böngészőben a látogatók, és fennáll a veszély, hogy el is feledkeznek az előző honlapról.

A fentiek ékes bizonyítéka a Google legújabb álláspontja: a weboldal sebessége is szerepet játszik a rangsorolásnál a Google kereső találati oldalán. Aminek viszont közvetlen hatása szokott lenni a cég pénzügyeire. A döntés egyébként érhető a Google részéről, hiszen nekik az a céljuk, hogy jó minőségű találatokat adjanak. És úgy tűnik szerintük is a gyorsabb weblap jobb.

Mit is jelent a weblap sebessége. Annyit, hogy látogató a cím beírást követően, vagy linkre kattintás után, mennyi időt kell várjon hogy az adott oldal teljes egészében megjelenjen a képernyőjén. Minél kevesebbet kell várnia, annál jobb. A várakozással eltöltött idő sok komponensből áll, amelyek két nagy részre bonthatóak: szerver oldali várakozás és kliens oldali várakozás. Mindkettő egyaránt fontos, de teljesen különböző technikák és eszközök szükségesek az optimalizációhoz.

Optimalizálás a szerver oldalon.

Ma már ritkán beszélünk statikus html oldalakról. Általában adatbázis alapú weboldalunkat egy program állítja össze, amelyet majd a webszerve szolgál ki. Az adatbázis például lehet MySQL vagy Postgres, a programnyelv pedig lehet PHP, Python vagy ASP.NET. Webszerverre példa az Apache vagy IIS. Ma már nem ritka, hogy nem egyedi program állítja össze az adatbázisból a weboldal HTML kimenetét, hanem valamilyen tartalomkezelő rendszert vagy keretrendszert használunk. Én a Drupal tartalomkezelő keretrendszert használom, de sok hasonló célú eszköz létezik, amelyeket szintén széles körben használnak. Általános célúak közül a Drupal mellett a Joomla népszerű még, de speciális célokra ott vannak a különböző blogmotorok, fórummotorok vagy wiki szoftverek is.

Bár technikailag a program része, mégis a tartalomkezelőt tekinthetjük egy negyedik komponensnek. Ezt a 4 komponenst (webszerver, adatbázis, keretrendszer, program) érdemes külön-külön megvizsgálni és elvégezni a szükséges finomhangolásokat, hogy a legkevesebb késlekedést okozzanak a weboldal megjelenítése során. A szerver operációs rendszert tekinthetjük egy ötödik komponensnek, de ennek a finomhangolása nem annyira a weboldal sebességénél számít, hanem nagy forgalmú oldalak skálázhatóságánál, ami egy egészen más dolog.

A beállításokra általános tanácsot adni nem lehet, mert az mindig a használt eszköztől függ. A fenti négyesből én az Apache + MySQL + PHP + Drupal kombinációt használom a leggyakrabban, ezeknek a beállításairól szeretnék majd később többet is írni.

Optimalizálás a kliens oldalon.

Ahhoz hogy a felhasználónál megjelenjen a weboldal a következőknek kell megtörténni:

  1. a böngésző kapcsolatot épít ki a kiszolgálóval
  2. letölti a html forrást
  3. letölti a szükséges egyéb komponenseket, úgymint képek, css stíluslapok, javascript-ek, és egyéb beépülő komponensek (mérőkódok, Videómegosztók, reklám zónák, stb...
  4. a böngésző lefuttatja a Javascript kódokat, amelynek eredményeként sokszor újabb komponensek letöltése szükséges

Amikor a fentiek mind befejeződtek, akkor mondhatjuk hogy a weboldal megjelent a látogató oldalán. Ez általában nagyon sokáig tart, leginkább a külső beépülő komponensek és reklámok miatt. A felhasználók pedig türelmetlenek, úgyhogy ezt sokszor meg sem várják, már továbbkattintanak. Ezt célszerű elkerülni, törekedni kell arra, hogy minél gyorsabban teljes egészében összeálljon a látogató képernyőjén az oldalunk. Itt egy kicsit könnyebb tippeket adni, nézzük sorban:

Az első lépés tulajdonképpen maga a szerver oldali teljesítmény optimalizáció. Annyi kiegészítéssel, hogy számít a böngésző és a kiszolgáló közötti fizikai távolság is. Ha a magyarországi olvasók a célcsoport akkor célszerű Magyarországon üzemeltetett szerveren futtatni a weboldalt.

A második lépénél túl sokat nem lehet variálni, de annyit igen, hogy a html-t Gzip tömörítéssel szolgáljuk ki.

A megjelenítéshez használt belső komponensek (képek, stíluslapok, JS fájlok) és külső komponensek (reklámok, web statisztika mérőkódok, videók) okozzák a lassulás legnagyobb részét. Ennek az optimalizálásával tudunk a legtöbbet nyerni.

Tulajdonképpen az alapszabály egyszerű, minél kevesebb komponenst használjunk, és ezek minél kisebb méretűek legyenek. A belső komponenseket csoportonként össze lehet vonni, és tömöríteni. Erre vannak speciális eszközök amelyek ezt a két lépést egyszerre elvégzik helyettünk. A külső komponenseknél egyszerű a helyzet: minél kevesebbet használjunk. Sokszor látni mérőkódokkal telepakolt weboldalakat: bekerül a medián webaudit, a gemius és a google analytics is. Miért ne, hisz "nem árthat" ha még több adatunk van. De bizony árthat, nem az adat, hanem az hogy a sok méregetés közben a látogatót fenntartjuk abban, hogy hozzáférjen az oldalunkhoz.

És ott vannak még a reklám zónák, amelyen nyilván üzleti szempontból kerültek oda. A gond az, hogy a Magyarországon legelterjedtebb reklámkiszolgáló szerverei néha annyira lassúak, hogy néha teljesen megakasztják az oldal letöltődését. Próbáljunk olyan reklámkiszolgálót használni, amelyik gyors.

A beépülő Youtube és Indavideók is jól meg szokták akasztani az oldalak használatát. Soha ne tegyünk be egyetlen oldalra egy lejátszható videónál többet. Ezt a Youtube is betartja a saját oldalain belül.

Az utolsó tennivalónk a kliens oldalon a Javascript-ek gyors futtatása. Ez erősen függ a webalkalmazástól, de általános tanácsot adni nem lehet. De érdemes minél kevesebb dolgot bízni a Javascriptre, amit csak lehet váltsunk ki CSS stílusokkal, ugyanis az sokkal gyorsabb.

Persze ne kifejezetten keresőoptimalizálási szándékkal vágjunk bele a fentiekbe, a Google-nél ez csak egy kis szempont. Inkább a látogatók általános megelégedettsége legyen a cél, és ezen is próbáljuk meg mérni az eredményeinket.

Oldalak

Feliratkozás Prunk-Éger Edgár RSS csatornájára