WWW-sivujen kännyversiolle käyttöliittymä

[Tapio X]

Kirjoitan itse oman CSS:ni. Jotkut luovat sisäkkäisiä lausekkeita. Jos ne lähettää W3C:n validaattorille, se ilmoittaa, että tiedosto on virheellinen.
Selain lukekee
#joku-valitsin{
.joku-valitsin {
}
joku-toinen {}
}
ihan mukisematta, mutta ei W3C. Tuollaisia oli teeman CSS:ssä yhdessä kohtaa. Ainakin yksi noista koodin siistijöistä tekee tuollaisia.

Olen yhdistellyt teeman ja bbPressin CSS:ää. poistin kokonaan bbPressin CSS:n käytöstä lapsiteeman avulla. Lisäosista voisi olla apua siivoamaan tuplat pois sekä yhdistämällä yhdistettävissä olevan CSS:n. Yritän kyllä yhdistellä ja poistella roskaa. Kun huomaan virheen, tulee tehtyä siihen CodeSnippetillä paikko. On varmaan paikkoja paikon päälle.

Kun nyt itse tunnet WordPressiä. voitko auttaa yhteen erittäin pahaan JS-ongelmaan, jonka ole kuvannut toisessa säikeessä. Haluaisin, että ns. mobiilivalikko olisi käytössä aina. Mobiilivalikon päätekohdalle on JS:ssä asetettu 1140px. Muutin raja-arvon 1140 arvoon 6000. Mutta eipä 1600px levyiseen näyttöön tullutkaan mobiilivalikkoa. Olin tätä ennen muuttanut CSS:ää siten, että valikoilla ei ollut taitepistettä lainkaan vaan valikko oli CSS:n perusteella sama kaikille. En nyt ymmärrä, mistä muusta homma voi kiikastaa kuin tuosta taitepisteen määrittävästä muuttujasta ja teeman CSS:stä. Oletin, että kun muutan molemmat, homma pelaa. Ns. pudotusvalikkoa ei aio hyväksyä millekään leveydelle. Sen pahin ongelma on se, että valikko ei aina mahdu näytölle ja jos mobiililaitteen viewport ylittää 1140px, mobiilissa on lähes totaalisen käyttökelvoton valikko. Pudotusvalikon kanssa kosketusnäytöllä menee hermot.
Jos en onnistu saamaan mobiliivalikkoa toimimaan kaikissa laitteissa luon isolle näytölle linkistä avautuvan linkkilaatikon, jossa näkyy kerralla kaikki päävalikon linkit + haku sekä muut lisäjutut, jotka aion jQueryn avulla valikkoon rakentaan.

 

[living_death]

Valitettavasti en osaa JS-koodia.

 

[Tapio X]

Itse osaan JS:ää foorumia ajatellen sen verran, että saan sillä haluamani toiminnallisuudet, mutta siihen meikäläisen JS-osaaminen päättyy. Olen opetellut jQueryä vain sen verran kun olen sitä tarvinnut, en yhtään enempää.

No jos en saa sitä JavaScript-ongelmaa ratkaistua, mitä mieltä olet siitä isosta valikkolaatikosta? Minkä kokoinen se saisi maksimissaan olla koskien sen leveyttä? Se iso valintalaatikko on nimittäin ainoa järkevä vaihtoehto. Olisiko sen laatija avaaja kiva olla sivustalla yläosan sijaan? Laadin laatikon kuitenkin vasta ihan pakon edessä.

 

[living_death]

Tarkoitatko valintalaatikolla menusysteemiä?

Jos tarkoitat, itse lähtisin rakentamaan sitä valmiilla plugarilla, jossa riittää valintoja enemmän kuin tarpeeksi ja samalla mitään ei olisi rikki erilaisilla päätelaitteilla sivua selatessa.

Max Mega Menu

 

[pekka666]

Täytyy sen verran kommentoida tähän väliin, että varmasti fiksu ratkaisu lähteä miettimään tuota toteutusta vähän uusiksi. Kuulosti siltä, että siitä vanhasta versiosta oli tullut sellainen sotku ettei siitä ota enää kukaan selvää.

Vähän veikkaan, että tuo hitausongelma johtuu http palvelimen hitaudesta. Näyttää tosiaan siltä, että selain joutuu odottamaan hetken ennen kuin saa mitään vastausta palvelimelta. Ei tuo mielestäni ole kuitenkaan vielä mitenkään sietämättömän hidas, paljon hitaampiakin sivuja tulee välillä vastaan.

 

[Kautium]

Vähän veikkaan, että tuo hitausongelma johtuu http palvelimen hitaudesta. Näyttää tosiaan siltä, että selain joutuu odottamaan hetken ennen kuin saa mitään vastausta palvelimelta. Ei tuo mielestäni ole kuitenkaan vielä mitenkään sietämättömän hidas, paljon hitaampiakin sivuja tulee välillä vastaan.

Siitä on ihan tutkimuksiakin, että missä vaiheessa käyttäjät luovuttavat jos sivun lataus kestää ja tuolla sivustolla se raja-arvo ylittyy moninkertaisesti. Aivan liian hidas ja kankea sivusto. Jos palvelimen kapasiteetti tulee vastaan, niin sitä saa rahalla lisää. Aiemmin huomasin jotain kerjäysyrityksiä, että voisiko joku sponssata lisää kapasiteettia, mutta ei se niin toimi.

Arvostan aloittajan viitseliäisyyttä ja päättäväisyyttä, mutta toisaalta osaaminen näyttää olevan hyvin rajallista ja asenne jääräpäinen.

 

[Tapio X]

Tarkoitatko valintalaatikolla menusysteemiä?

Jos tarkoitat, itse lähtisin rakentamaan sitä valmiilla plugarilla, jossa riittää valintoja enemmän kuin tarpeeksi ja samalla mitään ei olisi rikki erilaisilla päätelaitteilla sivua selatessa.

Max Mega Menu

En minä uutta valikkosysteemiä kaipaa kuin 1140px viewport-arvon ylittäville laitteille. Muille teeman valikko on kiva.
pekka666:lle. Kyllä minä osaan muokata WordPressiä varsin hyvin ja CSS on varsin hyvin hallinnassa. JavaScript-osaaminen on hyvin vajavaista ja riittää vain sen ymmärtämiseen, mitä itse on saanut aikaan. Ei riitä suurempien JS-kokonaisuuksien hahmottamiseen.

Itse arvioisin, että sivusto on foorumiksi noin kolme kertaa liaan hidas. Foorumini on siis vain foorumidemo.

Otin mukaan vanhasta mielestäni sopivia osia. Mukaan tuli turhaa, joka pitää siivota pois. Olen tehnyt siivoamista, mutta se on kesken. Asiaa voi verrata siihe, että pari muuttaa yhteen ja roinaa on yllin kyllin. Sitten pitää katsoa, mikä roina joutaa kaatopaikalle - kirppikseen ei CSS-roinaa voi viedä.

 

[pekka666]

Siitä on ihan tutkimuksiakin, että missä vaiheessa käyttäjät luovuttavat jos sivun lataus kestää ja tuolla sivustolla se raja-arvo ylittyy moninkertaisesti. Aivan liian hidas ja kankea sivusto. Jos palvelimen kapasiteetti tulee vastaan, niin sitä saa rahalla lisää. Aiemmin huomasin jotain kerjäysyrityksiä, että voisiko joku sponssata lisää kapasiteettia, mutta ei se niin toimi.

Arvostan aloittajan viitseliäisyyttä ja päättäväisyyttä, mutta toisaalta osaaminen näyttää olevan hyvin rajallista ja asenne jääräpäinen.

2 tai 3 sekuntia ymmärtääkseni tarjotaan usein rajana. Tässä omalla puhelimellani tuolle sivulle mennessä näyttää kestävän noin 4-5 sekuntia ennen kuin mitään tapahtuu, joten onhan tuo siinä mielessä liian hidas.

 

[Tapio X]

2 tai 3 sekuntia ymmärtääkseni tarjotaan usein rajana. Tässä omalla puhelimellani tuolle sivulle mennessä näyttää kestävän noin 4-5 sekuntia ennen kuin mitään tapahtuu, joten onhan tuo siinä mielessä liian hidas.

Foorumin pitäisi mielestäni toimia n. 1 sekunnin sisällä. Tähän nähden siis sivustoni on foorumiksi n. 3 kertaa liian hidas. Blogiksi sivustoni kelpaa, koska blogissa ei koko ajan vaihdeta sivuja eikä tule kommentteja, jotka pitäisi heti lukea.

Kun muutaman sivun selaa, aikaa menee 3-4 sek., eli hieman hidas blogiksikin, mutta menettelee. Yritän ensin heittää roskat pois ja katson, mikä on lopputulos. Jos en saa sivustoa toimimaan niin, että siirtymä on alle 1,5s. sivusto ei toimi foorumina.

Jos alle 1,5s. en pääse, vaikka teen kaiken, mitä osaan toiminnan nopeuttamiseksi, keskustelen ensin palvelun tarjoajan kanssa, mitä tehdä. Jos en saa järkevää tarjousta, ajattelin Sitegroundin palvelua - Suomessa hyvä WP-palvelu vaan maksaa ihan liikaa. Saisin Sitegroundilta kohtuuhintaan DNS ja CDN-pavelut.

 

[living_death]

Onko foorumin pakko olla nettisivulla?

Nykyään on ollut tapana perustaa FB-sivu ja hoitaa keskustelut sitä kautta ja sen hallinnoiminen on muutenkin helpompaa ja sinne löytäisi x kertaa useampi käyttäjä.

Jos olisin itse yhtä kiinnostunut sanaristikoista kuin @Tapio X niin haluaisin ehdottomasti liittyä sellaiseen FB-ryhmään, enkä keskustella asioista nettisivulla olevan foorumin kautta.

Nettisivu voisi olla sisällöntuottamista varten ja erottaa keskustelut sinne missä ne toimisivat parhaiten.

Tämä foorumi on ihan eri juttu, koska se on perustettu ihan oikealla foorumisoftalla, eikä millään Wordpressiin vajavaisella ja rumalla kikkareella.

 

[Tapio X]

En halua olla FB:ssä - kyse on siitä, että en luota Zuckerberiin.
XenForo on siisti paketti. Olet täysin oikeassa, että bbPress on oletuksena ihan älyttömän ruma. Olen ottanut XenForo-foorumeista mallia bbPress ulkoasun luomiseen. Kohtuullisen lähellä olen päässyt. bbPressi pahin puute foorumina on hälytyskello-toiminnon puute. En tunne WordPressiä niin hyvin, että osaisin lisätä sen bbPressiin. En myöskään tunne hälytyskellon logiikkaa. Pitäisi ensin ymmärtää se, miten tällä sivustolla selaimen välilehteen ilmestyvä muistutus ja sivun päänavigoinnissa näkyvä hälytyskello-ikoni toimivat. Jos osaat sen selittää, ehkä osaan tehdä siitä bbPress-version.

Kivinta WordPressissä on se, että jos mallinteen laittaa child-hakemistoon, voi mihin tahansa mallinteen kohtaan näppärästi lisätä omaa koodia laittamalla
do_action('tassa_on_jokin_nimi');

ja CodeSnippetilla
add_action ('tassa_on_jokin_nimi',... // anonyymi funktio tai funktion nimi
Lisäsin leivänmurut footer-osan yläpuolelle määrittämälla itse uuden do_action - add_action -parin.

<!-- #screenr_before_site_footer -->
<div id="screenr_before_site_footer"><?php do_action( 'screenr_before_site_footer' );?></div>

 

[Tapio X]

Semmonen JS-puute minulla on, että osaa lisätä elementille luokkia sen perustella, missä kohtaa sivua ollaan. Ymmärtääkseni tämän sivuston nuolet on jQueryllä, jossa luokkien vaihto on if-lausekkeen sisällä, joka tarkkaileen missä kohtaa näyttöä ollaan. En nuoliin vastaavaa kaipaa, mutta voisi ajatella laittaa hampulaisen eteen tekstin VALIKO, joka poistuu sopivan matkaa siirryttäessä. Tämä tarvitisi lisäksi useita if-lauseita näyttöportin koon mukaan

eli if($etaisuus=400 && $nayttoportti=1440){

...lisää tai poista luokka}

elseif{$etaisuus=300 && $nayttoportti=800){
...
}

 

[Tapio X]

Jätän sen mahdollisen laatikkomaisen valikon luontikokeilun myöhemmäksi ja jatkan toiminto- ja aihevalikoiden ymppäämisen kokonaisuuteen. Kuten näkyy, se istuu hyvin mobiilivalikkoon, mutta ei niin kivasti ehkä istuisi pudotusvalikkoon. No pudotusvalikkoa en saanut siististi leivänmurujen kanssa ja sen pystysuuntainen koko oli paikoin erittäin käyttäjäepäystävällinen. Laatikko on joka tapauksessa parempi vaihtoehto. Laatikkoon saa nätisti myös haun ja erityislinkit. Laatikon maksimileveys olisi 1140px varmaan aika passeli. Tällä hetkellä nuo linkit eivät tee mitään, joten ne pitää piilottaa.

 

[Tapio X]

Fiksu piirre tässä - voi vaihtaa tekstin leveyttä.

 

[Tapio X]

En löydä määrityksiä, joiden perusteella Foorumit – Tapion blogi & foorumi
jokaisella leveydellä pääsisällön alapuolelle tulee vaakaviivoja. Leveillä näytöillä tulee oikealle pystyviivat. Poistin sisältöalueet oikealla ja etsin sisältölohkoja, joilla voisi olla reunat, mutten löytänyt. Kun pakotin sisällön vähintään 750px leveyteen viivat jäävät joillakin leveyksillä ikävästi pääsisällön alle.
Tässä voi olla jokin grid-juttu, mutta en grid-määrityksiä, joissa näkyy reunoja, mistään löydä. Sitäpaitsi poistin gridit. Luokohan jokin JavaScript jotain ihmeellistä, jota ei CSS-tiedostossa ole ja jota ei pysty CSS-tiedoston kautta hallitsemaan?

 

[living_death]

Auttaisiko jos et näpertäisi pikseleillä, vaan ottaisit prosentit käyttöön, jolloin minäkin 3440x1440 näytöllä ei tarvitsisi katsoa tulitikkulaatikon kokoista laatikkoa?

 

[Tapio X]

Kerro, mikä olisi sopiva raja sille, että 1000px maksimileveys muuttuisikin prosenttiarvoiksi. Kun en omista noin isoa näyttöä, en pysty kuvittelemaan, mikä olisi sopivat prosenttiluku. Siis anna ehdotuksesi näihin ja kuinka monta niitä haluat.

@media screen (min-width:1601px){

. content-area {width:??%;min-width:???;max-width:???}

}

@media screen (min-width:????){

. content-area {width:??%;min-width:???;max-width:???}

}

Muistaakseni yli 940px teeman määrittämä fonttikoko on 15px. Ehdota fonttikokoja isolle näytöllesi.

Joudun todennäköisesti luomaan yli 1140px näytöllä valikkolaatikon. Voit ehdottaa sen koolle ja fontille arvoja omalle näytöllesi. Itse ajattelin maksimileveydeksi 1140px.

Teemassa on ihan helvetillisen pirullinen piirre. Teema luo PÄÄSÄLTÖELEMENTILLE ylimääräisiä luokkia right-sidebar ja left-sidebar. Ne on JS:llä, koska lähdekoodissa kyseisiä luokkia ei ole vaan ne lisätään JS:llä lennosta. Pirullinen seuraus tästä helvetillisestä lisäyksestä oli se, että oli vaikea saada rgb 333,333,333 1px reunaviiva pois.

#secondary{
    display: none!important;
}
.left-sidebar, .right-sidebar,#content,#content-inside,#primary,#main,#page{border-width:0!important}

Mutta edelleen leiskaan tulee näkymätön sivupalkki, jolle en ole CSS:llä määritellyt yhtään mitään!
Jokin hiivatin JS lisää CSS:ää, jota on vaikea hallita teeman tyylitiedostossa.

Ystävä hyvä, jotta selviät WordPressin leiskojen kanssa, sinun vaan pitää opetella jQuery addclass ja removeclass (tai miten nyt meni) käyttöä, että saat heivattua sellaiset luokkien lisäykset pois, jotka tuottavat harmia. Ne on todella pirullisia, jos ne tuottavat koodia, josta haluat päästä eroon. Et vaan saa haluamaasi lopputulosta, ellet muuta JavaScriptiä!

JavaScriptin tuottamasta ylimääräisestä koodista on se harmi, etten saa pääsisältöä aina keskitettyä ihan keskelle sivua. Minimileveys on sitä, että mennään voimalla se pirullisen oikean palkin päälle vähän kuin mentäisin puskutraktorilla naapurin aidan läpi. En millään keksi, miten saa tässä teemassa sisältöä aina aivan keskelle.

JavaScriptin tuottaman HTML:n kanssa on se ongelma, että sivuston lähdekoodia on turha katsoa suoraan. Sitä voi tarkistella vain paloin selainten työkaluilla. Niidenkin kanssa on vaike hahmottaa, mitä addClass(), removeClass() ja each(function() tekevät.

Yleensä on niin, että vain mobiilivalikko pelaa addClass(), removeClass() kanssa, mutta tässä leiskassa myös pääsisältöelementin kanssa pelataan noilla jQuery funktioilla. Sisältöelementi suhteen jQuery aikaansaa vain suhteellisen pientä ulkoasuvirhettä.

Pahempi ongelma on se, että en saa addClass() ja removeClass() funktioita toimimaan päävalikolle yli 1140px arvoisilla viewport-arvoilla.

 

[Tapio X]

Tiedän siis ongelmat, mutta en osaa niitä korjata. On sekin edistystä, että tietää, mistä ongelmat johtuvat. Jos joutuu puukottamaan pääteeman JS:ää, tilanne on ikävä. Jos muutettu JS toimii lapsiteemasta, ongelmaa ei ole muun suhteen, että päivitykset eivät muutetun JS-koodin kohdalla toimi. Minun JS-osaaminen on sen verran puutteellista, en jätä suuremman luokan JS:n puukotuksen tuonnemmaksi ja yritän ensin ratkoa muita ongelmia.

Päätyylitietoa pienensin 101 kB:tä ensin n,. 85 kbB ja minimoimalla 69 kB.
Ehkä olisi voinut poistaa vieläkin enemmän tavaraa, mutta en uskalla tällä hetkellä koskea siihen enempää.

Mitä sille voisi tehdä, olisi kokeilla, mitä joku CSS:n optimointisofta sille automaatiotoiminnoilla saisi aikaan. Varmaan pienentäisi kokoa tuosta. Mutta jos tekee sisäkkäisiä lausekkeita, tiedostoa ei voi validoida.

Yritän optimoida myös muut CSS-tiedostot. bbPressin tiedostossa on se hyvä puoli, että siinä ei ole yhtään turhaa ja tiedän jokaisen CSS:n merkityksen.

 

[living_death]

Kokeile prosentteja leiskan leveydestä?

Ihan hullua pakottaa pikseleihin.

Olen tehnyt tähän foorumiin kanssa oman leiskan ja kommentoinut aika huolellisesti mitä mikäkin tarkoittaa jos siitä olisi apua.

TechBBS - XenForo Dark Theme

Themes & Skins for the World's Top Websites

 

[Tapio X]

Kokeilen prosentteja yli 1140. Voin testata niitä välillä 1141-1600px. Mutta mielestäni 1000px on tuolle välillä ihan hyvä maksimiarvo. Juuri sen takia, etten pysty testaamaan, miten näet yli 1600 px leveyksillä, pyysin sinulta ehdotukset tuon arvon ylittäville laitteille. En voi edetä pidemmälle, kuin ymmärrykseni ja laitteen ominaisuudet riittävät.

Miten itse toimisit, jos olisit tilanteessa, jossa WordPress teeman JavaScript tuottaa samanlaisia ongelmia kuin minulla, mutta tehtävänäsi olisi luoda samanlainen lopputulos, mihin pyrin. Onko sinulla kaveria, jolle kilauttaa, että JavaScript-ongelmat saisi selätettyä?

Kyllä minä CSS:n kanssa pärjäilen, mutta JS on minulle paljon haastavampi asia.

Vasenta ja oikeaa marginaalia voi fiksata siten, että laittaa header-osan jälkeen ja footer osaa ennen

<div id="extra-content-wrapper">
...
</div>

@media screen and (min-width:...){
#extra-content-wrapper {margin-left:...} /* sitten vaan kokeilemaan */
}

Tää on muuten ihan toimiva vippaskonsti paitsi että sisältö ei aina ole ihan keskellä vaan on leveillä näytöillä aina ihan pikkaisen jommassa kummassa sivussa. Miten paljon sinusta haittaa se, että jos tarkoitus on keskittää sisältö, se ei ole ihan keskellä vaan vain melkein keskellä? Minun tapauksessa riittää, että sisältö on suurin piirtein keskellä. Mutta jos tekisit maksavalle asiakkaalle, hän voisi valittaa aika pienestäkin keskitysvirheestä.

 

[living_death]

Muistaakseni @ merkillä ja varmaan tiedätkin voi määritellä eri päätelaittellle omat resoluutiot css-koodissa?

Tämä on tämmöinen nopea heitto mitä voit itse alkaa työstämään ja joku muu tätä lukeva voisi antaa paremmat ohjeet.

CSS @media Rule

 

[Tapio X]

Tuosta ei ole apua, koska en saa tuolla haluamaani lopputulosta.

@viewport periaatteessa voisi auttaa.

Yleensä näkee, että @viewport on asetettu laitteen itsensä antaman arvon mukaan. Ei tullut mieleen, että tuota voisi yrittää manipuloida.

@viewport {max-width:1140px}

Tuosta ei ollut apua. Luin @viewport - CSS: Cascading Style Sheets | MDN:

Note: The use of <meta name="viewport"> tag overrides @viewport

WordPressille on

<meta name="viewport" content="width=device-width, initial-scale=1">

CSS:ssä @viewport on hyödytön. Ei siis ollut apua tuostakaan. Safari, Firefox ja Edge eivät näytä edes tukevan sitä.

Juttelin tyttären kanssa asioista. Tytär joutuu työskentelmään www-suunnittelijoiden kanssa. Hän kertoi että leiskoissa on piirteitä, joita ei haluta antaa muuttaa. Olen nyt kolmeen tämän tyypin asiaan törmännyt:

1. Valikkopainikkeelle ei saa taustaväriä.
2. Mobiilivalikon ja tietokoneen isolle näytölle olevan valikon vaihtumispistettä ei saa muutettua.
3. Leveältä näytöltä ei saa pois sivupalkkia.

Tytär sanoi, että noiden muuttaminen edellyttäisi teeman ydinkoodiin puuttumista eikä se ole järkevää. Pitäisi siis tulla toimee noiden ongelmien kanssa. Mitä voi yrittää:

1. Valikkopainike - valikkopainikeongelma ratkaistu siten, että laitoin valikkopainikkeelle emoelementin ja sille taustavärin ja 1px reunan.
2. Pitää rakentaa laatikkovalikko 1141+ näytölle - paska juttu, mutta vaihtoehtoa ei ole.
3. Sivupalkin merkitys pitää ohittaa brutaalisti:
   1. Pitää poistaa reunaviivat - onnistuttu.
   2. Pitää ajaa sivupalkin päälle - onnistuttu.
   3. Pitää siirtää pääsisältöaluetta oikealle
      1. Tökkäys ylimääräisen elementin avulla margin tai padding-ominaisuuksilla - ei onnistunut.
      2. Pääsisällön siirto position:relative avulla - onnistuu. Tällä tavoin sisällön saa suurin piirtein keskelle laitteella kuin laitteella, mutta hidastaako pääsisällön pakkosiirto sivujen lataantumista merkittävästi? Ongelmana on myös että pitäisi laatia paljon @media screen (min-width::?) {...}, jotta sisältö olisi suurin piirtein keskellä laitteella kuin laitteella. Itse pystyn laittamaan vain 1600px asti. Onko tässä järkeä ja miten paljon haittaa, jos sisältö ei ole keskellä vaikka se on tavoite?

 

[Tapio X]

Liitteenä kuva korjatusta painikeongelmasta. Jos joku katsoo, että värit eivät ole parhaat mahdolliset, vaihtoehtoisia värejä saa ehdottaa. Toistaiseksi ongelmana on se, että hover tulee muilta elementeiltä ja on nuolille väärä.

 

[Tapio X]

WordPress teeman ja bbPressin CSS:n yhteiskooksi tuli n. 160 Kb minimoitua CSS:ää. Molemmilta suurin piirtein yhtä paljon. Varsinkaan bbPressin puoliskoa on vaikea pienentää.

 

[Tapio X]

Otin yhteyttä palvelun tarjoajaan, jotta voitaisiin selvittää, mistä hitaus johtuu. Kerroin siitä tämän.

Kun tyhjensin Vivaldin (käytännössä Chrome) laskin sekunttarilla aikoja

Etusivu - Foorumit: 8s.
Foorumit - Suomen Kuvalehti: 6s.
Suomen Kuvalehti - jokin aihe: 5,5s.

N. 6s aika on n. neljä kertaa liian paljon. Sivustosta on blogiksi, mutta blogiosio ei pysty ainakaan annetuilla resursseilla olemaan muuta kuin blogin jatke, siinäkin huono. Foorumipuolella sivusto on foorumidemo. On tietenkin ihan kiva rakentaa demoa, mutta tarkoitus oli, että kyseessä ei olisi vain demo.

Olisiko mitään mahdollisuutta testata, olisiko sivustosta paremmilla resursseilla muuksi kuin demoksi?
...
Siivosin ja minimoin WordPressin sekä bbPressin CSS:n. Poistin turhat lisäosat ja tutkin koodini, jotta ne eivät aiheuttaisi toivotonta hitautta. En löytänyt pahaa virhettä, mutta koodissa saattaa olla resurssisyöppöjä kohtia. Olisi kiva, jos joku tältä varalta tutkisi koodini.

 

[Tapio X]

Muistaakseni @ merkillä ja varmaan tiedätkin voi määritellä eri päätelaittellle omat resoluutiot css-koodissa?

Tämä on tämmöinen nopea heitto mitä voit itse alkaa työstämään ja joku muu tätä lukeva voisi antaa paremmat ohjeet.

CSS @media Rule

Olisiko sinulla mahdollisuus käydä seuraavassa osoitteessa ja tutkia taustakäyttöä, jos annan pääkäyttäjän oikeudet.

Kirjaudu sisään ‹ Tapion blogi & foorumi — WordPress

www.sanaristikkofoorumi.net

Voisit katsoa:
CodeSnippet - omat koodini sitä ajatellen, että onko niissä resurssisyöppöjä koodauksia. En saanut functions.php toimimaan juuri mitään, joten lähes kaikki aktiivinen oma koodi on CodeSnippet avulla. Älä muuta mitään.
Vimpaimet - katso aktiivisten osien määritykset. Onko niissä kovin resurssisyöppöjä määrityksiä.

Onko kyse ensisijaisesti:

1. Palvelin on liian hidas tai palveluun on annettu liian vähän resursseja. Jälkimmäiselle voi joitain tehdä siirtämättä sivustoa muualle.
2. WordPress & bbPress on kombinaationa turhan raskas asentaessaan niin paljon kaikkea mahdollista koodia, ennen kaikkea paljon JS ja CSS-koodia, jotka ovat selaimelle raskaita. Tässä tapauksessa palvelimen tehostuksesta ei suurta iloa ole.
3. Onko koodauksessani resurssisyöppöjä kohtia tai olenko käyttänyt kovin resurssisyöppöjä lisäosia tai lisäosille kovin resurssisyöppöjä asetuksia.

 

[Tapio X]

Pelkään pahoin, että sivustoni jää demoksi - no WP:n kanssa tappeleminen on sinänsä kiva harrastus. Ainoa ikävä puoli siinä on se, että sitä ei voi tehdä tablet laittellani vaan pitää mennä istumaan tietokoneen ääreen. Pitäisiköhän tablet-laitteeseen hankkia bluetooth-näppis, jotta ohjelmointia voi tehdä löhöilemällä sohvalla?

 

[Hyrava]

Näyttäisi edelleen olevan sama ongelma jokoh CSS:n optimointi sun muut ei auta. Ongelmana sulla on sivun ensimmäinen request eli kun selain lähtee hakemaan sitä html-tiedostoa. Sen koko on ihan kohtuullinen ja pitäisi latautua millisekunneissa ainakin omalla nettiyhteydelläni. Loput tauhkat tulevat silmänräpäyksessä.

Tuo ongelma saattaa johtua siitä että sulla on mahdollisesti jotain huonosti käytäytyvää PHP-koodia tms joka siellä hidastaa sivun html:n generointia ja serveri miettii ja pureskelee sitä koodia 3-4 sekuntia ennenkuin html-tiedosto on valmis lähetettäväksi asiakkaan selaimelle. Saattaa olla jotain muutakin serveripään ongelmia mutta itse olen törmännyt juuri tuohon että sivun generoinnissa joku serveripään skripti jumittaa ja se aiheuttaa vastaavanlaisen viiveen heti alkuun.

edit:
Kokeilin laitailla noita sivun css-, javascript- ja muita tiedostoja suoraan ilman tuota itse sivun html:ää ja kaikki testaamani latautuivat millisekunneissa eli tuo ongelma on jotenkin tuossa itse html:ssä ja sen generoinnissa ja lähetyksessä selaimelle.

 

[Tapio X]

Itse asiassa epäilen jotain samaa, mutta en keksi, mikä voisi olla jumittava skripti. Olisiko sinulla aikaa tutkia asiaa seuraavilta osin.

1. CodeSnippet - omat koodini sitä ajatellen, että onko niissä resurssisyöppöjä koodauksia.. En saanut functions.php toimimaan juuri mitään, joten lähes kaikki aktiivinen oma koodi (pallukka ilmaisee, onko aktiivinen) on CodeSnippet avulla. Vain JS-tiedostojen haut on functions.php-tiedostossa, kun en muita saanut sitä kautta toimimaan. Älä muuta mitään.
2. Ulkoasu - Vimpaimet - lisukkeet - ks. aktiivisten osien määritykset. Onko niissä kovin resurssisyöppöjä määrityksiä tai ovatko jotkin lisäosat kovin resurssisyöppöjä.
3. Asetusten evästeet, joille ei ole käyttöä. Evästeiden määrittävä tietue ei juuri nyt ole käytössä, mutta jos vanha jäljellä jumittamassa.

Kirjaudu sisään ‹ Tapion blogi & foorumi — WordPress

www.sanaristikkofoorumi.net

Josko voisit kirjautua. Muutaisin käyttöoikeudet väliaikaisesti pääkäyttäjän oikeuksiksi. Tää on pakko nyt selvittää.

Omien lisäysten ohella asentamani lisäosat saattavat aiheuttaa ongelman. Yksi lisäosa on pari vuotta vanha eikä siihen ole päivityksiä. Täytyy kokeilla poistaa joitakin käytöstä

 

[Xanthe_]

Olen samaa mieltä Tapion kanssa ettei mitään FB ryhmiä. Vähän kuin tuputtais Suomessa käytettäväksi Paypalia maksuksi. Nope. Vai jos sitä kannattais laitetaas io-tech.fi alas ja siirrytään kaik FB:heen. Tuskin tulee kummoista tukea. Mieluiten tuen täällä käymistä mainostuloilla(kin) kuin jotain Zuckerbergiä mainostuloilla ja omien tietojen vuotamisella randomina aikoina. Toisena on se FB voi pistää foorumeita kiinni ihan omista syistä ja tilejä ilman että kunnoittaa sananvapautta jos satuttaa jotain korkeata henkilöä jollain vitsillä ihan suomenkin puolella kaverin tili jäädytetty jo montaa kertaa kun ärsytti esim. vihreiden edustajia jollain harmittomalla Greta vitseillä jossain ryhmässä ja leimas hänen puheet "vihapuheeksi". Eli käytetään systeemiä täysin väärin ja sille on täysin voimattomia FB mutkikkaan byrokratian takia jolloin parempi luovuttaa vain.

 

[Hyrava]

En taida olla oikea henkilö lähtemään kaivelemaan ongelmaa jostain wp:n hallinnan kautta kun ei wp:stä ole juurikaan kokemusta ja php:takin on tullut enemmälti koodailtua viimeksi vuosia sitten mutta itse lähestyisin tuota ongelmaa kommentoimalla tai poistamalla kaiken oman koodin käytöstä ja kokeilemalla paraneeko tuo tilanne sillä. Jos paranee niin sitten yksi pieni koodinpätkä kerrallaan takaisin käyttöön ja kokeilee missä vaiheessa rupeaa takkuamaan. Tuolla saa edes suunnilleen haarukoitua tuon ongelman sijainnin. Mahdollisesti kannattaa ottaa myös kaikki plugaritkin pois ensin päältä ja kokeilla onko joku niistä syyllinen.

Jotenkin on sellainen fiilis että siellä on joku järjetön if-lausehelvetti tai jotain luuppeja joiden suoritus kestää tuhottoman kauan ja ne aiheuttavat tuon hitauden. Tai sitten siellä on joku älytön tietokantakyselyhässäkkä jonka suoritus kestää odottamattoman pitkään.

Mutta tosiaan, ensin otat kaiken mahdollisen pois päältä ja sitten yksitellen rupeat laittamaan niitä käyttöön ja kokeilet missä vaiheessa tuo hyytyy.

 

[jad]

En mikään WordPress asiantuntija ole, mutta pari mieleen tulevaa seikkaa.

- sivusto näyttäisi olevan xetnet:llä hostattuna, omat kokemukset noista halvimmista hotelleista on aika huonoja. Saattaa osa php hidastelusta johtua yksinkertaisesti siitä, että sivustollesi ei yksinkertaisesti riitä prosessoriaika tuolla jaetussa ympäristössä. Markalla saa markan webhotellin.

- asenna esim. Query Monitor ja katsele läpi ensinnäkin se, paljonko tietokantakyselyitä suoritetaan ja niiden suoritusaika, näistä voit saada vähän vinkkiä siitä, mikä sivustoa hidastaa. Tuolla plugarilla saa tietokantakyselyiden lisäksi muutakin debug infoa irti sivulatauksista.

 

[Tapio X]

Hirveän isoa ero ei tullut missään vaiheessa. Poistin käytöstä kaikki ns. front-end-pluginit.
Backend pluginit jätin päälle, koska eihän niillä pitäisi olla merkitystä frond-end-puolen kanssa.
Kaikki front-end-pluginit pois päältä, tyhjä functions.php sekä vain CSS-koodin hakeva ja sitä hieman lisäävä CodeSnippet päälle kytkettynä tulos oli:

Etusivu - Foorumit: n. 5 sek. - aiempi 8 sek. TÄSSÄ on merkittävä ero.
Foorumit - Alifoorumi: n. 4,3 sek. - aiempi n. 6 sek. Melko suuri ero.
Alifoorumi - aihe: n. 3,4 sek. - aiempi n. 5,5 sek. Melko suuri ero tässäkin.

Sivun vaihto vie 3-4 sekuntia edelleen, vaikka lähes puhdas teema ja bbPress. Se on edelleen paljon ja liikaa foorumikäyttöä ajatellen.

Teemasta jäljellä yksinkertaistamani mallinteet, joissa on vain minimaalisia ero alkuperäiseen. CSS:n osalta siis se CSS, jota sivusto tarvitsee näyttääkseen kaiken oikein. CSS voisi jollakin ohjelmalla optimoida, joka hakee palasia yhteen ja näyttää ne paremmin. Joku ehdotti tähän jotain, mutten muista enää mitä ja kuinka kauan ehdotuksesta oli. Voisihan sitä kokeilla.

Ilman WordPressin ja bbPressin CSS:ää, mutta linkitetty JS mukana. Jos yksi CodeSnippet on pois käytöstä, poistuu kaikki WordPressin & bbPressin CSS pois käytöstä. Mukana nyt kaikki front-end-pluginit ja niiden asentama CSS. Tämä mittaa itse määrittelemäni CSS:n vaatiman ajan.

On muuten huomattava, että teema pakottaa käyttämään tietyn verran CSS:ää. Vaikka lapsiteeman CSS on tyhjä, valikoiden CSS on jäljellä. Se on kovakoodattu. Samoin on kovakoodattu jotkut värit. Teema ei siis ole ilman CSS:ää missään tilanteessa.

Etusivu - Foorumit: n. 7 sek. - omalla CSS:lläni sivulle siirryttiin n. 2 sek. nopeammin! Ero n. 30%.
Foorumit - Alifoorumi: n.5,7 sek. - omalla CSS:lläni sivulle siirryttiin n. 1,4 sek. nopeammin! En. n. 25%.
Alifoorumi - aihe: n. 7 sek. sek. - omalla CSS:lläni sivulle siirryttiin sivulle 3,5 sek. nopeammin! Ero 50%!

Keskimäärin selain siirtyi määrittelemälläni CSS:llä n. 65% verrattuna siihen, etten olisi määrittänyt CSS:ää.

CSS:ni ei voi olla huonoa, koska se nopeuttaa toimintaa. Koska enimmillään ero olsi 50%, sillä saattaisi saa vielä jonkin verran nopeusparannusta, mutta sillä tuskin saadaan ratkaisua.

 

[Tapio X]

En mikään WordPress asiantuntija ole, mutta pari mieleen tulevaa seikkaa.

- sivusto näyttäisi olevan xetnet:llä hostattuna, omat kokemukset noista halvimmista hotelleista on aika huonoja. Saattaa osa php hidastelusta johtua yksinkertaisesti siitä, että sivustollesi ei yksinkertaisesti riitä prosessoriaika tuolla jaetussa ympäristössä. Markalla saa markan webhotellin.

- asenna esim. Query Monitor ja katsele läpi ensinnäkin se, paljonko tietokantakyselyitä suoritetaan ja niiden suoritusaika, näistä voit saada vähän vinkkiä siitä, mikä sivustoa hidastaa. Tuolla plugarilla saa tietokantakyselyiden lisäksi muutakin debug infoa irti sivulatauksista.

Vaikutat olevan oikeassa testitulosteni perusteella. Vaikka poistaa kaikki hyödylliset front-end -pluginit, lopputulos ei ole kehuttava.

Yllätys oli sen sijaan se, että kun selain sain vain teeman pakkosyöttämän CSS:n, selain siirtyi sivulta toiselle hitaammin kuin lisäämäni CSS:n kanssa. Kun teema huomasi tyhjän tiedoston, se ehkä haki pääteemasta CSS:n.

Tuo testi osoitti kuitenkin sen, että CSS:n suunnitteluun kannattaa panostaa. Ero voi olla merkittävä.

Suuri yllätys oli se, miten paljon teema pakkosyöttää CSS:ää.

 

[Tapio X]

En taida olla oikea henkilö lähtemään kaivelemaan ongelmaa jostain wp:n hallinnan kautta kun ei wp:stä ole juurikaan kokemusta ja php:takin on tullut enemmälti koodailtua viimeksi vuosia sitten mutta itse lähestyisin tuota ongelmaa kommentoimalla tai poistamalla kaiken oman koodin käytöstä ja kokeilemalla paraneeko tuo tilanne sillä. Jos paranee niin sitten yksi pieni koodinpätkä kerrallaan takaisin käyttöön ja kokeilee missä vaiheessa rupeaa takkuamaan. Tuolla saa edes suunnilleen haarukoitua tuon ongelman sijainnin. Mahdollisesti kannattaa ottaa myös kaikki plugaritkin pois ensin päältä ja kokeilla onko joku niistä syyllinen.

Jotenkin on sellainen fiilis että siellä on joku järjetön if-lausehelvetti tai jotain luuppeja joiden suoritus kestää tuhottoman kauan ja ne aiheuttavat tuon hitauden. Tai sitten siellä on joku älytön tietokantakyselyhässäkkä jonka suoritus kestää odottamattoman pitkään.

Mutta tosiaan, ensin otat kaiken mahdollisen pois päältä ja sitten yksitellen rupeat laittamaan niitä käyttöön ja kokeilet missä vaiheessa tuo hyytyy.

Testien jälkeen tulin siihen johtopäätökseen, että vaikka ilman omaa ja lisäosien koodia sivusto nopeutui, nopeus ei kuitenkaan riitä yhdistelmän kunnolliseen pyörittämiseen. Kun lisää tarvittavat lisäosat ja oman koodin, loppulos on paha. Minä tekisin johtopäätöksen, että palvelinresurssit eivät riitä. Tuli rakennettua hauska leikkikalu. Leikkikaluna www-sivusto hauska, mutta tietenkin sitä toivoo, että www-sivusto voisi toimia sellainena, kuin se on ajateltu.

No toimii kyllä juuri ja juuri blogina, mutta siinäkin hitaus haittaa. Tykkään kyllä kehittelystä. Nyt sivustoni on julkinen kehittelypaikka. Ei sivustoani kannata mainostaa oikeana foorumina, jos palvelinpuolelle ei saa kunnolla rautaa alle.

Niin, on pohdinnan paikka tyydynkö leikkikaluun vai haluanko ihan oikeasti olla kunnon foorumin ylläpitäjä. En nyt osaa sanoa juuri tähän hetkeen vastausta. Jos en halua satsata kunnon palveluun, tykkään kuitenkin leikkiä nykyisellä palvelimella - palvelimen kanssa leikkiminen kun on kuitenkin ihan kivaa touhua.

 

[jad]

/wordpress/forums/ sivun lataus:
- yhteensä 56 sivupyyntöä (Not great, not terrible)
- 1,6Mt
- lataus 5,39s
- html contentin lataus 4,11s
- DOM valmis 4,5s
- sivu valmis 5,44s

HTTP/2 hieman parantaisi kokonaisaikaa, koska selain voisi ladata useampaa assettia rinnakkain. Tätä tuskin saa webhotellista erikseen kytkettyä päälle.
CSS optimoinnilla voit oikeastaan vaikuttaa vain tuohon DOM valmis - sivu valmis väliseen aikaan. Selvästi pullonkaula on PHP ja/tai mysql puolella.

Edit: Saattaa mennä osaamisalueesi ulkopuolelle, mutta väittäisin, että halvinkin (~3€/kk) Hetznerin pilvipalvelin pesisi nämä tulokset mennentullen. Vaatii tosiaan vähän palvelinosaamista, sellaisenaan tuo on vain 'tyhjä' linux purkki.

 

[Tapio X]

Latausajat ovat samaa luokkaa kuin mitä tein sekunttikellon kanssa. Sain pahempiakin aikoja, mutta myös pienempiä.

CSS:n suhteen optimointi ei siis auta tuon perusteella paljon, mutta miksi silti sain oman CSS:n kanssa niin suuren eron kuin sain?

Palvelun tarjoajalle kertoman neljä kertaa liian hidas toiminta on siten varsin oikein arvioitu. Tykkään kuitenkin hirveästi leikkikalustani ja vaikka se jäisi leikkikaluksi, haluan sen pitää vaikka vain ja ainoastaan leikkikaluna.

Täytyy omalta osaltani pitää varteenotettavana foorumina Suomi24:ää. Siellä on oikea foorumi. Yhtä nopeasti toimivasta Sanariksen foorumista minut savustettu ja ajettu ulos, joten minulla sanaristikoiden suhteen oikeana foorumia vain Suomi24.

Sanariksen pomo kyllä on lukenut kommenttejani Suomi24:ssä ja "foorumillani", joten on oma sivustoni jonkinlainen palautekanava Suomi24:n ohella. Yksi nettituttu teki nopeasti toimivan chatin. Siinä on ollut satunnaisesti paljonkin kävijöitä.

Kun nyt "foorumini" on lelu, voitaisiinko täällä suhtautua siihen vain visuaalisena demona ja keskustella siitä, mikä demossa on hyvää ja huonoa.

Demon rakentelua haittaa kyllä paljon se, että teema pakkosyöttää paljon CSS:ää ja JS:ää, jolloin tietyt asiat eivät ole ollenkaan minun komennettavissani. Yli 1140px pitäisi luoda oma valikko. Pitäisi asentaa jokin plugari, jolla sen saisi aikaan. Se pitäisi sitten mobiililaitteilta piilottaa. Perseestä, mutta en voi oikein mitään pakkosyötetyille JS + CSS -toteutuksilla. Tai ehkä voisin, mutta sitten pitäisi käydä tiedosto tiedostolta teeman jokainen rivi lävitse ja sitten teemasta pitäisi tehdä ihan oma versio.

Muuten kyllä, mutta JavaScript-osaamiseni on varsin puuttellista. JavaScript-koodin muuttaminen ja osan JavaScript-koodin poistaminen kokonaan, olisi varsin iso työ. No olisihan se hyvä harrasteena. Ei ainakaan tekemisen puute pääse yllättämään!

 

[jad]

CSS:n suhteen optimointi ei siis auta tuon perusteella paljon, mutta miksi silti sain oman CSS:n kanssa niin suuren eron kuin sain?

Saattaa johtua esim. siitä, etä testeissäsi osa asseteista ladattiin suoraan oman selaimen välimuistista. Mahdollista myös se, että teeman ja/tai lisäosien CSS:ää generoidaan php:lla inline- koodiksi tms.

Chromella F12 avaa developer consolen, sieltä Network välilehti ja täppää Disable Cache päälle, niin tuon developer- ikkunan ollessa auki selaimen välimuistia ei käytetä. Näin saat tasaisempia mittaustuloksia.

 

[Tapio X]

Koska teeman tyhjän CSS-koodin kanssa sivu näytti normaalilta, aika paljon sitä generoidaan PHP:llä. Mutta kun oli oma CSS, miten se pystyi ohittamaan tuon generoidun CSS:n, tutuu ihmeelliseltä.
Varsinkin se eka siirtymä ihmetyttää. Tyhjensin aina aluksi selaimen välimuistin. Ensimmäiseen siirtymään ei siten välimuistissa pitänyt olla mitään haettavaa.

Tein muuten uuden ennätyksen CSS:n heivaamisessa. Olin luonut edelliselle teemalle varsin toimivan CSS:n. Kun uusi teema joka tapauksessa pakkosyöttää CSS:ää, en tarvitse mitään teeman alkuperäisestä CSS:stä vaan käytän edellisen teeman jäljiltä muokkaamaani CSS:ää. Hävisi 69 kB CSS:ää kokonaan pois käytöstä.

Teeman alkup. CSS 101 kB, joten 101 kB CSS:ää on poistettu käytöstä. Laitoin yleiselle osalle uutta CSS:ää 15 kB eli teemalle annetaan alkuperäiseen nähden 85 kB vähemmän CSS:ää!

Foorumi, mutta vain foorumi saa 77kB.

Lisäksi on hieman paikkoja. Kun ne lasketaan mukaan olen määrittänyt 95 kB CSS:ää.

Foorumin CSS:n alkuperäinen koko oli 30 kB, joten olen laatinut foorumille paljon uuttaa CSS eli n. 45 kB. Kokonaisvähennys on siten 40kB.

Voi tosin olla, että teema kaivaa alkuperäisestä tiedosta takaisin jotain CSS:ää. En ehkä tiedä, kuinka paljon teema käyttää sitä.

Minulle oli tämän teeman kanssa suuri yllätys, miten paljon se estää käyttäjän tekemiä CSS-muutoksia. Tytär tiesi kertoa, että tällä tavalla valmiit paketit usein toimivat.

 

[Hyrava]

Hirveän isoa ero ei tullut missään vaiheessa. Poistin käytöstä kaikki ns. front-end-pluginit.
Backend pluginit jätin päälle, koska eihän niillä pitäisi olla merkitystä frond-end-puolen kanssa.
Kaikki front-end-pluginit pois päältä, tyhjä functions.php sekä vain CSS-koodin hakeva ja sitä hieman lisäävä CodeSnippet päälle kytkettynä tulos oli:

Niin, backend-plugareilla EI PITÄISI olla merkitystä mutta yllättäen niillä saattaakin olla merkitystä, samoin tuo CodeSnippet. Sen takia nimenomaan tuo testaus pitäisi aloittaa niin karsittuna kuin mahdollista vaikka sivu näyttääkin silloin luultavasti lähinnä oksennukselta. Tosin, en kyllä ihmettelisi jos tuo nykyinen palvelinhotellisi vaan olisi niin huono ettei sivusi jaksa sen päällä pyöriä.

 

[Tapio X]

No täytyy jossakin vaiheessa vielä tehdä testi ilman lisättyjä lisäosia. Vain mukana tuleva Akismet kannattaa jättää. Tai ehkä sekin pitää ottaa pois päältä.

Yritän tutustua teeman "sielunelämään". Näemmä tämäkin asentaa ikonifontin. fontawesome-webfont. Pitäisi tutustua, mitä se sisältää.

Jos ei mitään tähdellistä, fontin voisi heivata pois ja korvata ikonit WordPressin mukana tulevalla dashicons-ikoneilla.
Vaiva on vain siinä, että pitää verrata, mitä kummastakin löytyy. dashicons ei välttämättä löydy kaikkia.

 

[Tapio X]

Palvelun tarjoaja muutti nyt asetuksia, joilla pitäisi nopeutua.

Etusivu - Foorumit: 6,5 - alkuperäinen 8s.
Foorumit - Suomen Kuvalehti: 6s.
Suomen Kuvalehti - jokin aihe: 4,7s.
Aihe - blogi 5,3s.

Ei suurta eroa. Keskimäärin 5-6 sek. Aika toivotonta.

Kokeilen vielä autoptimize tyhjällä cachella:

Etusivu - Foorumit: 4,6 - alkuperäinen 8s. - selkeä ero
Foorumit - Suomen Kuvalehti: 7,1 - 6s. HIDASTUI SEKUNNIN
Suomen Kuvalehti - jokin aihe: 5,7 - 4,7s. HIDASTUI SEKUNNIN
Aihe - blogi - 8,9 5,3s. HIDASTUI 3,5 SEKUNTIA

Autooptimize siis hidastaa eikä nopeuta.

 

[Tapio X]

Tytär kehotti vaihtamaan murupolun väriä sinertävän suuntaan. Kopsasin kokeeksi tältä foorumilta värin. Tytär kertoo mielipiteen joskus, pitikö siitä - samalla saatte palautteen pitääkö hän tämän sivuston yläpalkin väristä.

 

[Kautium]

Ei niitä latausaikoja millään sekuntikellolla kannata katsella. Selaimesta löytyy suoraan kehittäjätyökalut, josta näkee suoraan mikä vaihe kestää minkäkin verran.

Tytär kertoo mielipiteen joskus, pitikö siitä - samalla saatte palautteen pitääkö hän tämän sivuston yläpalkin väristä.

Kaikella kunnioituksella olen melko varma, että sen kummemmin tämän foorumin käyttäjiä kuin ylläpitoakaan ei kiinnosta tyttäresi mielipide sivuston yläpalkin väristä.

 

[Tapio X]

Isosta näytöltä. Jos haluan antaa isolle näytölle muun kuin pudotusvalikon eikä käytössä ole JS:ää, onko jollakulla hyviä CSS-ehdotuksia.
Sais tästä demosta siten jotenkin isollakin näytöllä toimivan kun saan sorkittua riittävästi teeman koodia.

 

[Tapio X]

Yritän sopia palvelutarjoajan uutta diiliä. Esitin, että palveluntarjoaja antaisi sellaiset resurssit, että sivulta toiseen siirtyminen tapahtuu alle 1,5 s. Minä puolestani tekisi ilmaiseksi muutoksia palveluntajoajan asiakkaan WordPress-teemoihin. Minulle on kertynyt aika paljon kokemusta siitä, millä tavoin leiskokja voi muuttaa. Uusimman leiskan kohdalla tuli kyllä myös vastaan se, mitkä ovat muuttamiskykyni rajat. Rajojen vastaan tulo tuli minulle kyllä eräänlaisena shokkina.

Teemassa on paljon sellaista JS:ää, joka pakkosyöttää tietyt asiat toimimaan ja näytämään tietyllä tavalla. Ensimmäisen kerran törmään siihen, että leiskan pääsisältöaluetta hallitaan jQueryn avulla. Seuraus tästä on se, että teema pakkosyöttää vasemman palkin. Ei auta, vaikka poistat CSS-tiedostosta kaiken palkkiin liittyvän CSS:n ja määrität, että sitä ei ikään kuin olisi olemassa. Teeman JS-systeemi yliajaa käyttäjämuutoksia. Tyttäreni tekee www-sunnittelijoiden kanssa yhteistyötä ja hän kertoi, että nykyisin jotkut asiat kovakoodataan JS:llä. Kovakoodattuihin seikkoihin hänen mukaansa ei juuri kukaan puutu. Palkin merkityksen kumosin ajamalla pääsisältöelementillä palkin ylitse vähän kuin ajamalla autolla suojatiellä kävelevän ylitse. Joitakin muutoksia osaan tehdä tehdä vain brutaalisti.

Valmisleiskojen muuttamisessa on siis rajoitteita, jotka on tunnustettava. Mutta osaan poistaa ja lisätä valmisleiskoihin melkein mitä vain. Kokonaisia lisäosia en ole opetellut luomaan, mutta olen niiden palasia hyödyntänyt bbPress-puolella. Lisäystaidoistani on esimerkkinä sivuston leivänmurut. Leivänmurujen generoimisessa on kaksi eri funktiota, omat perus WordPressille ja omat bbPressille. Olen yhtenäistänyt niiden emoelementit ja olen sijoittanut ne paikkoihin, jotka edellyttävät koodin tuntemista. Toinen paikoista oli valmiina, toisen rakensin. WordPress leiskoihin voi yhdellä ainoalla koodirivillä luoda paikan, jonka avulla leiskaan voi lisätä melkein mitä tahansa, vaikka dieaesityksen sivun alkuun. Tämä siis koskee leiskapohjaa. Silmukalla tuotetun sisälllön keskelle ei voi luoda omia lisäyksiä: Lisäyksiä voi tehdä niihin kohtaan leiskaa, jotka on HTML:llä kovakoodattu.

Esitin, että jos palvelutarjoanan asiakas haluaa kustomoida teemaa, teen kustomoinnin ilmaiseksi. Kustomoinnissa en kuitenkaan koskisi seikkoihin, jotka on kovakoodattu JavaScriptillä. Sellaisten muuttamiseen ei taitoni riitä. Osaan kyllä dynaamisesti lisätä jQueryn avulla sisältöä leiskaan esimerkkinä Google-haun ymppääminen osaksi valikkoa. Sen olen toteuttanut jQueryllä. JavaScript osaaminen rajoittuisi niihin seikkoihin, joissa teemoissa muutenkin hyödynnetään jQueryä. Luokkien lisääminen ja poisto ja korvaavan sisällön luominen ovat yleisimmät jQueryllä toteutut asiat.

Vasineeksi palveluntarjoaja antaisi niin paljon resursseja, että foorumisivulta pääsee toiselle sivulle alle 1,5 sekunnissa.

Mitä yhteen jQuery-juttuun tulee, yhtä en ole saanut toimiaan enkä keksi, missä on vika. Aina ennen minun kaikki jQuery-viritelmäni ovat toimineet.

Suoranainen aukko JavaScript-osaamisessani on se, että saada jokin elementti näkymään tai piiloutumaan kun on siirrytty tietty matka. Nykyisten nuolten koodi on nettitutulta saatu, en ole sitä itse koodannut. Pitäisi opetella koodaamaan vastaavia itsekin. Niitä käytetään uusissa leiskoissa paljon. Jos joku palveluntarjoan asiakas haluasi sellaisen lisättyä, en osaa tällä hetkellä lisätä.

Juuri muuta kuin näitä kolmea asiaa ei valmisleiskohin tarvitse lisätä.

Mikä olisi hyvä sivu opetella JS-aukon paikkaamiseksi? On paha sanoa, että asiakas haluaa, että x komponentti häviää tietyin ehdoin sivulta, enkä osaa lisäyksen JS:ää toteuttaa.

Tosin tässä on yksi suuri mutta. Kuten jokainen on huomannut, minulla on taipumusta pikku huolimattomuusvirheisiin. Ne olivat aikanaan liikaa ja voi olla, että palveluntarjoaja ei nytkään luota siihen, että olen tarpeeksi huolellinen.

 

[Tapio X]

Siihen toimimattoomaan jQueryyn. Ongelma on se, että

$('.side-opener-left').click(function() {
var y = document.getElementById("tabC");
if (y.style.display === "block") {y.style.display = "none";}
var x = document.getElementById("tabA");
x.style.display = (x.style.display === 'none') ? 'block' : 'none';
})           
$('.side-opener-right').click(function() {
var y = document.getElementById("tabA");
if (y.style.display === "block") {y.style.display = "none";}
var x = document.getElementById("tabC");
x.style.display = (x.style.display === 'none') ? 'block' : 'none';
})

Ei nyt toimi yhteen niitä vastaavien luokkien kanssa. elementit, joiden id on tabA ja tabC ovat olemassa.

class="side-opener-left"
class="side-opener-right"

Kun joku ei toimi, on joskus vaikea löytää syytä toimimattomuuteen. Jossakin saattaa olla syntaksivirhe, mutta olen syntaksin tarkistanut. Joskin Online Javascript Validator - BeautifyTools.com edellyttää, että "})" perään pitäisi laittaa ";" eli pitäisi olla "});". Vastaavat koodit ovat toimineet ilmankin, joten ei se siitä voi olla kyse. Olisiko silti hyvä käytäntö laittaa ";" perään?

Vaihdoin vanhanaikaiseen koodiin, joka toimii kuin entiset VR:n vessat.

 onclick="showTabA();return false"
  onclick="showTabC();return false"

Kun en saanut jQueryä toimimaan, ei sen kanssa kannattunut jäädä vatvomaan. Minulla on vanhanaikaisestikin toteutettuja juttuja ollut edellisessä leiskassa, mutta ajattelin, että hoitasin nyt asioita enemmän jQueryllä.

 

[Tapio X]

Testasin vielä sivuja. Palvelin hakee tavallisia sivuja ihan riittävän nopeasti. Ongelmana on, että bbPress-osasto ei toimi riittävän nopeasti.
Nopeus riittää vallan mainiosti blogiksi ja artikkelien julkaisuun, mutta ei foorumille.
Heti kun siirrytään foorumipuolelle, toiminta hidastuu.

Teeman otsikon hallinta on *piip*. Se lykkää artikkeleille ja foorumille otsikoksi "BLOGI". Swiper-otsikot piti poistaa asia-artikkeleilta ja foorumilta. Blogiartikkeleille jää tavallinen otsikko, mutta foorumipuolella sivun nimi näkyy vain leivänmuruissa (tai sitten olen jossakin välissä ottanut tavalliset otsikot pois näkyvistä, asia pitää tarkistaa).

Otsikoiden hallinta on taas sellainen yllätyksenä tullut asia, johon en pysty vaikuttamaan - mitä lie kompleksia JavaScriptiä, jota ei parane mennä sorkkimaan. Mitä voisi kokeilla on:

body.bbPress .swiper-slide-heading,body.single-post  .swiper-slide-heading {font-size:0!important}

body.bbPress .swiper-slide-heading ::before {content:"FOORUMI";font-size:...;...}

body.single-post  .swiper-slide-heading ::before {content:"ARTIKKELI";font-size:...;...}

 

[Tapio X]

Poistin aiemman roskakirjautumisen estämiseen tarkoitetun ohjelman. Vanhentunut lisäosa hidasti kuulemma sivujen toimintaa. Sen tuki päättyi 2019. Se esti tehokkaasti robottien luomat käyttäjätilit.

Asensin tilalle Googlen Captchan ja laitoin sen käyttön joka lomakkeella.
Vastaavasti poistin pakollisen kirjautumisen.

Minulla oli v2 avaimet. En löytänyt sivuja, joilla asettaa v.3. Yritän joskus päivittää versioon 3.
Voiko joku laittaa tarkan osoitteen, josta v.3:n asennuksen voi aloittaa. Yritin etsiä sivuja, mutten vaan löytänyt. Olen vähän huono hakuhommissa.

Cachen tyhjennys - vastaa eka kertaa sivuille saapuvan tilannetta.

Etusivu - Foorumit: 5-6s - alkuperäinen 8s. - selkeä ero, mutta neljä kertaa hidas.
Foorumit - Suomen Kuvalehti: 4,3s - 6s. - selkeä ero, mutta kolme kertaa liian hidas
Suomen Kuvalehti - jokin aihe: 3,9s - 4,7s. - selkeä ero, mutta kolme kertaa liian iso
Aihe - blogi - 5,5s. - kaksi kertaa liian hidas.
Aihe - toinen tavallinen sivu 3s. - juuri ja juuri riittävän nopea tavalliseksi sivuksi
Jokin artikkeli - 6s. - kaksi kertaa liian hidas blogisivuksi (joskus vei paljon enemmänkin, mutta sivu oli pitkä)
Jokin artikkeli - lyhyt artikkeli 3s. - juuri ja juuri riittävän nopea blogisivuksi

Tavallisia sivuja vaihtuu n 3 sek. ajassa, mikä juuri ja juuri riittää blogille. Artikkelisivut toimivat hieman liian hitaasti.

Foorumille sivujen vaihtuminen on lisäosan vaihdonkin jälkeen n. kolme kertaa liian hidasta. Tilanne ei paljoa parantunut eikä sivustosta ole edelleenkään foorumisivustoksi.

Vanhentunut lisäosa hieman hidasti sivujen latautumista, mutta vaihto toiseen ei paljoa auttanut. Uusi lisosa toimii kuitenkin taustakäytössä paremmin ja sen voi määritellä monipuolisemmin. Edellin koski vain kirjautumista ja rekisteröitymistä.

Palvelun tarjoaja ei reangoinut ehdotukseeni mitenkään.

 

[Hyrava]

Tuo kolme sekuntiakin on todella pitkä aika. Monet tavalliset sivut joissa on paljon javascriptiä, kuvia, tekstiä sun muuta ja jopa mainoksiakin latautuvat alle sekunnissa. Joku 5s on jo niin paljon että herkästi tulee jo suljettua tuollainen välilehti ennenkuin sivu kerkiää edes latautumaan. Nykypäivänä vaan on tottunut siihen että ei tarvitse odotella nettisivujen latautumista ikuisuuksia.

Jos kerran ongelma on palveluntarjoajassa niin vaihda palveluntarjoajaa...