JavaScriptiä Firefoxissa natiivikoodin nopeudella. Ei ole vaikea nähdä missä on sovellusten tulevaisuus.
The goal of the TraceMonkey project — which is still in its early stages — is to take JavaScript performance to another level, where instead of competing against other interpreters, we start to compete against native code.
External JavaScript files block downloads and hurt your page performance, but there is an easy way to work around this problem: use dynamic scripts tags and load scripts in parallel, improving the page loading speed and the user experience.
Ennätystehtailu johti niin suureen Firefox 3:n kysyntään, että Mozilla palvelimet jumittuivat jo ennen h-hetkeä ja jumitus jatkuu edelleen. Toivottavasti ruuhkahuippu hellittää ennen latausvuorokauden päättymistä.
Webissä pääasiallinen tulonlähde ovat mainokset. Mainokset palvellaan useimmiten kolmannen osapuolen palvelimelta. Tekniikka jättää paljon toivomisen varaa. Puhtaasti tekniset ongelmat voidaan onneksi aina ratkaista.
Seuraavassa luetellut ongelmat pohjaavat pääasiassa kokemuksiini nykyään AOL:n omistuksessa olevan saksalaisen ADTECHin Helios IQ -tuotteesta, mutta myös muista yleisistä järjestelmistä.
Bannerit on toteutettu kukin omalla markup-mössöllään. Mainonnanhallintajärjestelmä tarjoaa omia aataminaikaisia templatejaan, mainostoimisto käyttää toisia yhtä kamalia, ja kaikki lataavat omat kiertotapansa IE:n Eolas-ongelmaan ja Flashin selainyhteensopivasti sivulle liittämiseen.
Sen sijaan, että sivun kaikki bannerikoodi noudettaisiin yhdellä HTTP-kutsulla, jokainen banneripaikka kutsuu mainospalvelinta erikseen ja saattaa saada vastaukseksi vain ohjeet noutaa sisältöä ihan toiselta palvelimelta. Aikaa palaa ja selain odottaa vastausta ennen kuin voi aloittaa seuraavan bannerin kutsumisen. (Kuulemma jossain järjestelmässä tämä ongelma on ratkaistu.)
Tänä web-APIen kulta-aikana mainosten integrointi JavaScriptin avulla kuulostaa hätäratkaisulta. Hidasteleva mainospalvelin, tai hidasteleva yhteys mainospalvelimelle hidastaa sivun latautumista. Käyttäjät syyttävät — aivan aiheesta — itse sivustoa hidastelusta, vaikka mainospalvelin olisikin varsinainen syypää. Mikäli “tagi” on sijoitettu viisaasti, hidastelu ei estä sisällön näyttämistä, mutta vaikka tällaiset kiertokeinot toimivat, niitä ei pitäisi joutua käyttämään eikä varsinkaan itse implementoimaan.
Mainoksia ei voi täysin hallita mainonnanhallinnassa, koska järjestelmä ei ajattele kohdesivustoa kokonaisuutena vaan yksittäisinä banneripaikkoina. Paikkojen ja niiden sisältämien tagien hallinnointiin on isolla sivustolla rakennettava oma järjestelmänsä. Ongelma ratkeaisi sillä, että bannerikoodi lukisi sivun (selkokielisen) URLin ja määrittäisi sen ja järjestelmään syötettyjen URL-sääntöjen mukaan sopivan bannerin. Koko hallinnointi kuitenkin selvästi on mainonnanhallintajärjestelmän tehtävä, eikä sitä pitäisi joutua paikkailemaan omilla virityksillä.
Mainosbannerien tiedostokoolle on asetettu rajoituksia, mutta aina näitä ei osata tai viitsitä valvoa. Usein ladattavaa kertyy kohtuuttomasti. Fiksu mainonnanhallintajärjestelmä osaa kertoa mainosta syöttävälle, jos tiedoston koko ylittää asetetut rajat, mutta se ei osaa tehdä mitään, jos mainos palvellaankin toisesta järjestelmästä tuoden vain mainos-tagit omaan mainonnanhallintaan.
Minun koneellani se toimi ihan hyvin.
Varmasti, mutta onko se vähän vanhempi kone, pyörikö samalla viisi muuta yhtä raskasta banneria ja yrititkö samalla tehdä jotain muutakin?
Joku voisi joskus laskea, kuinka monta ydinvoimalaa voisi jättää rakentamatta, jos Flash-bannerit kiellettäisiin tai bannerivelhot opetettaisiin tekemään konetehoja vähän vaativaa animaatiota.
Mainonnanhallinta-ala kaipaa kipeästi standardeja ja innovaatiota. IAB:n mainoskoot ja standardit eivät enää riitä. Tarvitaan yleiskäyttöisiä JavaScript-kirjastoja kaistantarpeen minimoimiseksi, yhteensopivia APEja eri järjestelmien ristiinkäyttämisen mahdollistamiseksi, älykkäämpiä mainonnanhallintajärjestelmiä integrointityön minimoimiseksi ja vaikka mitä.
Mainonnanhallinta 2.0, missä viivyt?
Uuden Adobe Readerin käynnistyminen kestää tolkuttoman pitkään. Prosessia voi nopeuttaa merkittävästi ottamalla lähes kaikki ilmeisen turhat pluginit pois käytöstä. Tämä tapahtuu helpoiten Darrell Nortonin ohjeiden avulla:
Nyt Reader käynnistyy hetkessä aikaisemman, jopa useamman kymmenen sekunnin, odottelun sijaan!