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

Tapio X sanoi:
En toki pidä. Kun jokin asia, josta olen maininnut, on selvinnyt, tiedotan, että siitä ei tarvitse enää käsitellä. Tulee kirjoitettua aika spontaanisti, mitä asioista tulee mieleen.

On kirjoittelu välillä juttuseurankin hakemista.
Napsauta laajentaaksesi...
Hyvä kun viimein tunnustit. Tätä on moni epäillyt monessa mediassa.

Mutta tiedotat? Ei, se nyt vaan ei mene niin, että omalla alustallasi kerrot, ettei jotain asiaa saa käsitellä missään muualla. Katso @Kautium postaus tuosta edeltä.

Tapio X sanoi:
Mitä kritiikkiin tulee, minua on läpi elämäni kritisoitu ties mistä. Kritiikki työstä kuuluu asiaan. Minusta erään toisen sivuston kritiikki puree ongelmiin niitä liioittelematta. Niitä kritisoimassani visuaalisessa toteutuksessa on monta. Mitä tämän säikeen alkuperäiseen teemaan tulee kyseinen sivusto toimii nimen omaisesti kännykässä varsin siististi.
Napsauta laajentaaksesi...
Moni osaa ottaa kritiikin vastaan ja sen perusteella pyrkiä parantamaan omaa osaamistaan.
Mutta ei, tässäKIN kohdassa sinä vähättelet täällä sinulle kohta 20 sivun verran tajottua monen alan osaamista. En tiedä, ymmärrätkö asiaa mutta kommenteissa on ollut mukana monta alan ammattilaista. Ammattilaista, joka on tarjonnut ilmaiseksi vinkkiä, ajatusta, osaamista...


Tapio X sanoi:
Juttelin Suomi24:n kanssa kommenteista. Kyllä siellä moderaattori hyväksyi toisista foorumeista sitaatin ottamisen. En tee mitään väärää siteeratessani, jos lähde on esillä eikä sitaatti ole hyvän tavan vastaisesti käytetty.
djmake sanoi:
Samalla lopetat muiden kommenttien kopioimisen omille sivuillesi.
Napsauta laajentaaksesi...
Jätän tämän kommentin huomiotta. Tähän en sitoudu.
Napsauta laajentaaksesi...
Todella hieno asenne! Toivottavasti jokainen tähän ketjuun kommentoiva huomioi tuon. Eli kommentoit mitä tahansa, kommenttisi voidaan irroittaa asiayhteydestä, kopsata muualle ja kommentoida sitä miten tahansa.

Ja ei, et kerro mitään lähdettä riittävästi. Lainauksia nimimerkiltä x ja siinä kaikki. Tosin valitettavasti en ottanut screenshotteja joten enpä ihmettele, jos olisit siivonnut pahimmat omalta sivustoltasi.

Mielestäni kuitenkin aivan käsittämätön asenne! Viesti on hyvin pitkälti teos, eikä sinulla ole oikeutta irrottaa sitä omaksi kokonaisuudekseen omille sivuillesi millään "tämä on iotekistä"-tyyppisellä maininnalla tai ilman sitä.

Suomi24:n ajatuksella taas yrität sekoittaa pakkaa. Kyse oli OMILLE SIVUILLESI tekemistäsi kopioista ties mistä viesteistä.

Tapio X sanoi:
Pyydän anteeksi liikaa kirjoittelua - paha tapa vähän kaikkialla. Tällä hetkellä ei ole merkittävää ongelmaa. Palvelun tarjoaja lupasi antaa käyttöön enemmän tehoja, joten senkin suhteen pientä parannusta on toiveissa.
Napsauta laajentaaksesi...
Montako kertaa on tästäKIN sinulle sanottu? Aika monesti eikä silti oikein mene perille.
No, nyt ei ollut vastauksia vielä mutta älä editoi edellistä viestiäsi kovin pitkän ajan jälkeen JOS ei ajatus ole sekoittaa keskustelua. Kun katselee muutamia vanhoja edittejä, syy lienee juuri tämä.

Kumpikohan muuten on totta, lisää resursseja vai siirto muualle? Liekö edes ok kysyä, miten kiristit antamaan ilmaiseksi kaiken vain sinulle? Kysyn kuitenkin koska en ymmärrä, miksi kukaan kustomoisi ilmaiseksi sitä halvinta webbihotellia.
 
Sain lisää resursseja.

djmake sanoi:
Ja ei, et kerro mitään lähdettä riittävästi. Lainauksia nimimerkiltä x ja siinä kaikki.
Napsauta laajentaaksesi...
Sanariksen foorumiin linkityksissä on yleensä linkki Sanariksen foorumiin. Linkkiä ei ole jos ihan lähellä on linkki viittaamaani keskusteluun. Kun en voi suoraan foorumiin kommentoida, kommentoin noin ja toivon, että foorumin vastaava sattuisin myös minun kommenttini lukemaan joko omasta foorumistani tai Suomi24:stä. Olisin toki halunnut laittaa kommentin suoraan siteeraamani kommentin perään, mutta se on minulta kielletty.

Kun tilanne on tämä, en voi oikein muutenkaan toimia. Pitäisikö laittaa www-osoite näkyviin eikä laittaa kommenttiin vain pelkkä linkki?

En hirveästi täältä ole sitaatteja sivuilleni ottanut. Jos olenkin ottanut, olen ottanut kommentteja, jotka ovat hyviä. En ole täällä käyviä juuri moittinut. Olen kyllä maininnut, että täälläkin on joskus ollut ilkeitä kommentteja.

Myönnän, etten ohjeita ole riitävästi noudattanut. Pahin asia on se, että aikoja sitten joku kehotti vaihtamaan teemaan. Paikallisen palvelimen pystytystä olen yrittänyt, mutta kun se ei ole onnistunut se on jäänyt. Nyt sain konkreettisen vaihtoehdon Windows WAMPille. Sitä en juuri nyt tarvitse, koska mitään suurempaan muutostarvetta ei tällä hetkellä ole ja minulla on erillinen testisivusto, jossa voin testata kriittisimmät muutokset. Sivustoni CSS kaipaisi vielä kerran huolellisen tarkastelun, jossa yhdistäisi eri paikoissa olevia sääntöjä toisiinsa ja poistaisin kaiken mahdollisen turhan sälän. CSS:ää sivuillani on liikaa. Siivoaminen on kyllä puuduttavaa hommaa.

Chromen (käyttöliittymänä Vivaldi) Lighthousella tekemäni testi osoitti, että suurin resurssien kuluttuja on turha JavaScript. Se on puolta suurempi hidastaja kuin turha CSS. Voin saada kaiken turhan CSS:n pois teeman ja bbPress CSS:stä. Muiden lisäosien kuin bbPress CSS:n siivoamiseen en ryhtyisi. Ehkä muidenkin kuin bbPressin CSS:n saa screenr-child -alaisuuteen, jolloin pystyisin optimoimaan myös muiden kuin bbPress CSS:ää. Periaatteessa saattaisin päästä eroon turhasta CSS:stä, mutta se on kovan työn takana.

Mutta turhan JavaScriptin siivoamista teemasta ja lisäosista en osaa. Lisäosat päivittyvät automaattisesti, joten lisäosien JS:n ei kannattaisi puuttua lainkaan. Turha JS on vain minun pakko hyväksyä.

Todennäköisesti XenForossakin on turhaa JavaScriptiä. Tuskin kukaan Suomessa alkaa siivoamaan XenForon JS:ää. Turha JS on mahdollisesti XenForonkin rasite. En ole kyllä tutikinut XenForoa. Oletan, että tilanne ei ole paljon parempi. Mutta voihan XenForo olla tässä suhteessa parempikin.

Uskoisin, että erittäin harvalla Suomessa on olisi osaamista siivota WordPressin, bbPressin ja muiden lisäosien CSS. Se on sitäpaitsi niin suuren työn takana, että tuskin kukaan siihen ryhtyisi. Valmiit ratkaisut syövät resursseja, mikä on vain hyväksyttävä tosiasia.

Minä olen itse luonut melko vähän uutta JavaScritp-koodia. Sitä on niin vähän, ettei sen pitäisi olla ongelma. Se ei ole tällä hetkellä yhdessä tiedostossa. Oman JavaScript kohdalla voin vain yhdistää skriptit. Uskaltaako skriptit pakata kuten CSS:n? Mikä on netistä löytyvä paras pakkaaja, Ajattelin, että ensin laitan pakkaamatta ja testaan sillä ja lopuksi pakkaan JS:n.
 
Viimeksi muokattu:
JS:n tarkistamisesta

Online Javascript Validator - BeautifyTools.com

Online Javascript Validator validates javascript code and find errors and warnings that can be fixed. See real time validation of your javascript code as you type.
beautifytools.com beautifytools.com
edellyttää, että esimerkin viimeisen"})" perässä olisi ";" ja valittaa "Missing semicolon.", jos sitä ei ole. Skripti toimii ilman sen lisäämistä. Olisiko ihan validointisyistä hyvä se aina lisätä - miten toiset tekevät:
Koodi: 
$('.open-tabC').click(function() {
$('.open-tabC').addClass('active-tab');
$('.open-tabC').removeClass('normal-tab');   
$('.open-tabA').removeClass('active-tab');   
$('.open-tabA').addClass('normal-tab');   
})    // tähän siis validaattori kehottaa laittamaan loppuun ";"
 
Jos nyt palataan pari vuotta taaksepäin ja kokeillaan uudestaan sellaista, että jätät sen sivustosi muutamaksi kuukaudeksi rauhaan ja opiskelet jostakin muualta perusteet näistä tähän liittyvistä aiheista.

Nyt sinä sähläät koko ajan omiasi, oletat kaikkea ihmeellistä ja kyselet typeriä, kun et suostu näkemään vaivaa teorian eteen, etkä kuuntelemaan ohjeita.

Tapio X sanoi:
JS:n tarkistamisesta

Online Javascript Validator - BeautifyTools.com

Online Javascript Validator validates javascript code and find errors and warnings that can be fixed. See real time validation of your javascript code as you type.
beautifytools.com beautifytools.com
edellyttää, että esimerkin viimeisen"})" perässä olisi ";" ja valittaa "Missing semicolon.", jos sitä ei ole. Skripti toimii ilman sen lisäämistä. Olisiko ihan validointisyistä hyvä se aina lisätä - miten toiset tekevät:
Napsauta laajentaaksesi...
Jokaisella ohjelmointikielellä on oma syntaksinsa, jota pitää noudattaa. Vaikka joku asia toimisikin koodien ollessa vähän sinne päin, on ihan mahdollista että puolipisteen puuttuminen jostakin aiheuttaa ongelmia toisaalla jne.

www.w3schools.com

W3Schools.com

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.
www.w3schools.com www.w3schools.com
 
Viimeksi muokattu:
Ok.
Myönnettäköön, että JavaScript osaamisessani on puutteita. WP:n teemoille omien lisäysten tekemiseen osaamistaso melkein riittää. Vain kaikki, mikä liittyy ikkunan hallintaan, ei ole hallinnassa. Aukkoja pitäisi paikata.

Ensiksi yhdistin oman JS:n ja siirsin kaikki JS-tiedostoon. Ei sitä paljon ole, yhteen 6kB.

Ajattelin, että sitä ennen teen CSS:n siistimisen CSS:n yhdistämisen. Kyseessä on suuri urakka. Sillä ehkä saavuttaisi 0,3-0.5 s. vauhdin parantumisen. Voisin päästä ehkä 1,6-1,7s keskimääräiseen sivun latautumiseen. Mutta se on ehdoton maksimi, minkä minä omilla toimenpiteilläni voin saada aikaan.

Lighthouse valitti myös kuvista, mutta kaikki kuvat on optimoituja, joten niitä ei voi enempää optimoida. Jos eläisin USA:ssa, olisi järkevää asentaa ShortPixelin Adaptive Images, jossa kuvat haetaan optimikokoisina firman CDN-palvelimelta. Kännykälle siis tarjotaan bittikooltaan pienempiä kuvia. Mutta kun palvelin on USA:ssa, sahaaminen Suomen ja USA:n välillä aiheuttanee sen, että CDN:stä optimikokoisten kuvien haku kännykällä on hitaampaa kuin se, että selain pienentää kuvan kännykkään sopivaksi. ShortPixelin Image Optimizer on määritelty "glossy" ei tasoa hieman lasketaan, mutta ei käytetä tasoa, joka voisi merkittävästi laskea kuvien laatua.

CSS:n optimointi on ainoa asia, minkä minä itse voin tehdä sivujeni nopeamman latautumisen hyväksi.
 
Viimeksi muokattu:
Etusivun joku koki hyvänä:
On hyvä. Riesoo aina kun johonkin firman sivulle menee, niin
ei löydä etsimäänsä. Tärkeää on, että kun tulee ensi kerran
jollekin firman sivulle pitää ensi silmäyksellä olla niin selkeä,
että löytää mitä hakee...
Tässä ensi sivulla olet tavoittanut tuon idean.....
Napsauta laajentaaksesi...
 
Tapio X sanoi:
CSS:n optimointi on ainoa asia, minkä minä itse voin tehdä sivujeni nopeamman latautumisen hyväksi.
Napsauta laajentaaksesi...
Sisällön optimoinnin ja virheiden poiston lisäksi voit myös maksaa kunnollisesti palvelinkapasiteetista, kuten kaikki muutkin. En ymmärrä puheita sponsoreista jne, kun koko alusta on noin pahasti sekaisin. Ei mopolla mahottomia, vai miten se sananlasku sanoikaan.
 
Ei n. 2 sek. siirtymiseen enää kovin paha aika ole. Sain myös tallennustilaa riittävästi. Enempää siltä palvelimelta ei ole luvassa. Enkä ole valmis maksamaan maltaita foorumin ylläpidosta. Foorumia ylläpidetään yleensä yritystasolla tai yhteisöissä. jotka saavat mainosrahoitusta. Foorumien ylläpitoa ei yleensä kukaan yksityinen henkilö eikä mikään firma kokonaan maksa.

Kun tämä on tilanne ainoa tapa optimoida on tosiaan CSS:n ja sisällön optimointi. Siihen aion tarttua kun jaksan.

Sisällön optimimoinnilla kaiketi tarkoitat sitä, että ei laita samalla sivulle liikaa sisältöä vaan jakaa tarvittaessa sisältöä yhden pitkän sivun sijaan usealle sivulle. Tämäkin asia tulee tarkistaa. Minulla on joitakin ylipitkiä sivuja, joita olisi syytä jakaa. Hyvä muistutus sisällön optimoinnin tarpeellisuudesta. Muutamien sivujen jakaminen onkin käynyt mielessä, mutta on jäänyt toistaiseksi tekemättä.

Suoranaisia koodausvirheitä ei pitäisi olla ellei sellaiseksi laske sitä, että CSS:ssä on tarpeettoman paljon edellisten määritystä kumoamisia. Kaikki tarpeettomat kumoamiset pitää poistaa (teeman tai lisäosan CSS:n yliajo voi olla tarpeellinen yliajo).

JavaScritini olen validoinut, joten niissä ei ole koodausvirheitä. Lisäsin ne validaattorin vaatimat puolipisteet kaikkiin kohtiin, mistä se ilmoitti ne puuttuvan.

PHP ei voi olla syntaksin osalta virheellistä, sillä jos se olisi sivut olisi nurin. CodeSnippet myös tarkistaa huolellisesti syntaksin eikä pieninkään syntaksivirhe jää huomaamatta. Toinen kysymys on se, olenko käyttänyt PHP:tä järkevästi. Mielestäni olen, mutta olen itse asiaa huono arvioimaan.
 
Tapio X sanoi:
Ei n. 2 sek. siirtymiseen enää kovin paha aika ole. Sain myös tallennustilaa riittävästi. Enempää siltä palvelimelta ei ole luvassa. Enkä ole valmis maksamaan maltaita foorumin ylläpidosta. Foorumia ylläpidetään yleensä yritystasolla tai yhteisöissä. jotka saavat mainosrahoitusta. Foorumien ylläpitoa ei yleensä kukaan yksityinen henkilö eikä mikään firma kokonaan maksa.
Napsauta laajentaaksesi...
Taas kuvittelet omiasi. Jokainen tuolla tasolla operoiva palvelu on kehittäjänsä itse maksama. Mainosrahoitusta ja vastaavia on mahdollista saada vasta sitten kun on pohja kunnossa ja voi osoittaa että sivustolle on tarvetta ja siellä on riittävästi kävijöitä.

Tapio X sanoi:
Sisällön optimimoinnilla kaiketi tarkoitat sitä, että ei laita samalla sivulle liikaa sisältöä vaan jakaa tarvittaessa sisältöä yhden pitkän sivun sijaan usealle sivulle. Tämäkin asia tulee tarkistaa.
Napsauta laajentaaksesi...
Tarkoittaa yleisesti ottaen sitä, että kaikki palvelimen käyttäjälle tarjoamat resurssit on optimoitu ja että matkalla ei ladata turhaa tauhkaa mistään, saati sitten jostakin kolmannelta osapuolelta.

Tapio X sanoi:
JavaScritini olen validoinut, joten niissä ei ole koodausvirheitä. Lisäsin ne validaattorin vaatimat puolipisteet kaikkiin kohtiin, mistä se ilmoitti ne puuttuvan.
Napsauta laajentaaksesi...
Validaattori ei ota millään tasolla kantaa siihen millaista kuraa koodi itsessään on, tai onko siinä pahoja logiikkavirheitä. Validaattori tarkistaa syntaksin, ei mitään muuta. Järkevillä kehitystyökalulla ulkoisten validaattoreiden käyttö on tarpeetonta.
 
Kautium sanoi:
matkalla ei ladata turhaa tauhkaa mistään, saati sitten jostakin kolmannelta osapuolelta.
Napsauta laajentaaksesi...
WordPressin suhteen sitä ei voi taata. Katsoin koodia. On idioottimaista, että teemaa linkittää https://... sen sijaan että käyttäisi teeman itsensä laataamia tiedostoja relatiivisesti. Ei mitään järkeä, mutta en minä osaa tuohon järjettömyyteen puuttua.

Googlen palvelut lataavat kolmannen osapuolen sivuilta. Muita tällä tavoin toimivia front-end-plugineja minulla ei pitäisi olla. Täytyy vielä tarkistaa asia. Lomake saattaa käyttää kolmannen osapuolen materiaalia.

Validaattori ei ota millään tasolla kantaa siihen millaista kuraa koodi itsessään on, tai onko siinä pahoja logiikkavirheitä. Validaattori tarkistaa syntaksin, ei mitään muuta. Järkevillä kehitystyökalulla ulkoisten validaattoreiden käyttö on tarpeetonta.
Napsauta laajentaaksesi...

Tiedän. CodeSnippet validoi PHP:n ja osittain CSS:ää ilmoittaen joistakin virheistä, mutta ei ole kunnon JS tai CSS-validaattori. W3C validaattori ei pidä oikeana koodina joidenkin softien luomia sisäkkäisiä CSS-sääntöjä vaan merkkaa ne virheiksi. Joku joskus mainitsi jonkun CSS-koodin siistijäohjelman, mutta en muista mikä se on.

Manuaalinen optimointi on hidas prosessi. Itse arvioisin, että optimoimalla kaiken CSS:n, mikä on palvelimelle ladattu, voisin nopeuttaa latausta 0,3-0,5sek. sivu. Mitä sinä luulet. Onko 0,3 sek./sivu syytä tehdä paljon töitä?
 
Viimeksi muokattu:
Tuskin saat edes tuota 0.3-0.5s nopeutusta vaikka kuinka optimoisit tuota CSS:ää. Ihan vaikka Firefoxin inspectorilla katsomalla nuo css:t latautuvat ehkä muutamissa kymmenissä millisekunneissa eli kaikista niistä tulisi ehkä juuri tuo 0.3 sekuntia yhteensä. Eniten latautumisessa aikaa kestää ulkopuolisista lähteistä haetut asiat eli kaikenlaiset googlen gstatic-osoitteesta ladatut fontit sun muu vastaava tauhka mutta nekin latautuivat ehkä parissasadassa millisekunnissa. Suurin hidastehan tuossa edelleen on se ensimmäinen lataus jossa ladataan sivun html, siihen kestää jo se 2 sekuntia.

En katsellut niin kovin tarkkaan mistä virheilmoitukset ja varoitukset tulivat mutta pari kuvaruudullista niitä näytti olevan. Jotain cookie-virheitä, tuntemattomia css-määrittelyitä ja javascript-virheitä ainakin näytti olevan. Voi olla että ovat sinun koodistasi, voi olla että ovat ulkopuolisten koodista. Kannattaa ainakin ne kurkata läpi, joku niistä saattaa aiheuttaa jotain hassua tai odottamatonta.
 
  • Tykkää
Reactions: hmb
Välillä sivut latautuivat n. 2 sek. Cache auttoi varmaan tuohon pääsemisessä.

En käytä tuntemattomia CSS-määrityksiä, joten ne ovat muiden koodista. Lisäämiäni evästeitä käsittelevä tiedosto on pois käytöstä. Joten niistä ei voi johtua jos sitten aiemmin määritellyt jotenkin häiritsevät. Omissa skripteissä ei ainakaan ole syntaksivirheitä.

Valituksia tulee jQuery is not defined sekä se että, funktiota ei käytetä. Jälkimmäinen on minusta tyhmä valitus. Vaikka funktiota ei käytetä skriptin sisällä, sitä voidaan kutsua onclik jne. tapahtumankäsittelijöillä. Tuo valitustyyppi on minusta typerä.

Teeman skriptin kun heitin validaattoriin, alkoi validaattori valittaa hyvinkin paljon. Liian kompleksi skripti korjattavaksi niin, ettei valituksia tule. Teeman koodaaja ei saa kovin korkeita pisteitä JS:tä. Teeman JS:n valitukset täytyy ohittaa. Uskon, että kaikki JS-valitus tulee juuri niistä. Katsoin, että validaattorin marmatus teeman JS:tä koski vähäpätöisiä seikkoja. En kyllä itse voisi kirjoittaa JS:ää, joka validaattorin heitettynä aiheuttaa niin paljon mussutusta. Teeman JS:ään tuli tutustuttua, kun piti hieman puukottaa sitä, että sain valikot toimimaan mobiiliversion tavoin kaikilla leveyksillä. Heitin siinä vaiheessa pari JS-tiedostoa mainitsemaani validaattoriin.

Kyllä nuo valitukset on yksinomaan muiden koodausten takia. Ainakin JS-ongelmat täytyy kestää. JS:n fiksaamiseen tarvittaisiin kunnon ammattilaista.

Vaikka nyt ei nopeusetua tulisi, bbPressille luomani CSS on syytä käydä läpi, kun se on luotu edelliselle teemalle. Se toimii lähes optimaalisesti uudenkin kanssa, mutta huomasin CSS:ää tarkastellessani, että joitakin ristiriitoja siinä on. Ei kovin suuria, koska toimi varsin hyvin. bbPress on siitä rasittava, että merkittävä osan sen CSS:ää täytyy luoda uusiksi, että saa tyylikkään lopputuloksen. Ilman muokkausta lopputulos on amatöörimäinen räpellys. Esikuvana muutoksille olen käyttänyt XenForo-foorumeita.

CSS:ssä ei kyse ole vain koosta, vaan siitä, miten selain sitä käsittelee. Jos on huonosti laadittu, tulee ylimääräistä työtä. Sitä oma CSS osittain tekee. Kun on ylimääräistä työtä selaimelle, selaimen prosessointi kestää.

Kyse on sekä palvelimen että selaimen prosessoinnista. Selaimella menee tietty aika kun sen käsittelee saadun JS:n, CSS:n ja HTML:n ja luo niiden pohjalta sivun. Tässä prosessoinnissa voin vaikuttaa CSS:n loogisuuteen. @media lohkot pitäisi olla loogisessa järjestyksessä ja liikaa uudelleenmäärittelyjä ei saisi olla, muuten aikaa tärväytyy. Se saattaa olla paljon pahempi ongelma kuin CSS:n lataus. Samoin huonosti suunniteltu JS voi olla hidaste, vaikka itse JS latautuisi nopeasti.
 
Viimeksi muokattu:
Tekijöitä on monenlaisia ja niin on niitä virheitäkin. Kaikki virheet eivät ole fataaleja, mutta toisaalta pienikin virhe voi olla sellainen. Olennaista on ymmärtää mistä mikäkin johtuu ja mikä vaikuttaa mihinkin.
 
En nyt jaksa uskoa, että on olennaisia virheitä. Katsoin lisäosien lisäämää CSS:ää. Osoittautui hyvin vähäiseksi. Kaikissa vain se, että haettiin https://... eli haku vei enemmän aikaa kuin käyttö. Idioottimaista, kun kerran tieto olisi haettavana nopeammin palvelimelta. WorPressissä on ihan järkyttävän paljon dataa, jota se haettaa nimipalvelimen kanssa ties missä kulkien, vaikka tiedostot ovat palvelimella. Vain hyvin harva tiedosto pitäisi hakea https://.... Sellaisia ovat lähinnä Googleen liittyvät tiedostot. Turha JS on hidastin, mutta sitäkin enemmän taitaa olla haku https avulla ja varsinkin jostakin Googlen palvelimelta. WordPress voisi yleisesti toimia nopeammin, mutta suunnittelijoina on kyllä joukko idiootteja ainakin mitä tulee tarvittavien tiedostojen hakuun.

Tarkastelin bbPressin CSS:n. Ei ollut mitään maininnan arvoista vikaa eikä hirveästi päällekkäisyyksiä. Siivoamista oli merkityksettömän vähän. Käyn silti teeman CSS:n vielä läpi enemmänkin ollakseni itse paremmin selvillä sisällöstä.

Listasit hyvin ulkoiset haut. Googlen Captha on tarpeen, mutta Analytics ei tarvitsisi olla omalla sivustolla. Onhan tiedot löydettävissä myös netistä Googlen omilta sivuilta. Tosin sieltä vähän hitaammin. Kokeilen pistää pois käytöstä, jos se hitusen hyödyttäisi.

Et nyt millään kertoisi, millä sivulla saisin Captcha v. 2:n rinnalle v.3:n, kun en kerta kaikkiaan muista, missä sivu oli enkä osaa hakea.
 
Viimeksi muokattu:
Hyrava sanoi:
Mitäs muuta eroa paikallisesti kehittämisessä on kuin että omien nettisivujen osoite on eri? Jos se kehityskone on internettiin yhteydessä niin samalla tavalla ne netissä olevat linkit ja resurssit toimivat. Ihan samalla tavalla se oma kehitysserveri sitä sivustoa hostaa kuin joku palveluntarjoajan serverikin.
Napsauta laajentaaksesi...
Ei mitään eroa, vaan se kehitystyö tehdään muualla kuin livenä ja muutokset tehty sivu siirretään WP:ssä plugarilla takaisin palvelimelle.

Ainut ero voi olla latausnopeuksissa kun tavaraa ei haeta palvelimelta ja senkään ei pitäisi nyky-yhteyksillä olla ongelma, jos ei ole ihan euron kotisivutilaa ostanut ja sieltä tahalleen rajoitettu liikennettä halvan hinnan vuoksi.

Yleensä olisi hyvä olla ainakin pari tietokantaa, mielellään vaikka viisi ja mahdollisuus alidomaineihin.

Tiesit varmasti tämän, mutta laitoin muille tiedoksi.
 
Mutta jos linkki on nettiin, et ole enää paikallisella palvelimella. Osaa sivuista ei siksi voi paikallisesti testata. Toki voisi kokeilla laittaa eri osoiterakenteen. Mutta en tiedä, miten foorumit ?id=xxx merkattaisiin. En ajatellut valikon linkkejä riittävän kauskantoisesti, kun osa on omia linkkejä. Sivuja ei voi navigoida paikallisesti.

Minulle riittäisi se netissä oleva testisivusto, mutta se ei toimi nyt kunnolla eikä se nyt kelpaa edes testaukseen. Syytä oikkuiluun en ole keksinyt. Ja onhan sekin jossakin määrin julkinen.

Tällä hetkellä on vain viimeistelyä. Mutta jos mieleen tulee rakentaa jotain ihan uutta, toki voisi ajatella paikallistakin palvelinta. Puuttuva ominaisuushan bbPressistä on tämän sivuston kaltainen hälytys, mutta voi olla liian vaikea toteuttaa.

Se jonkun mainitsema Local kiinnostaa.
 
Viimeksi muokattu:
Täytyy joskus kokeilla. Juuri nyt on vain CSS:n tarkistus. Sitä vähän JS:ssä kummeksuin, kun pistin yhden JS:n tiedostoon, se lakkasi toimimasta. Lähempänä käyttötarvetta eli <script>... sisällä toimi (jQuery).
 
CSS:ssä tärkeintä on loogisuus. bbPress tarkistin loogisuuden. Muutama @media ... oli väärässä järjestyksessä. bbPress listausten näyttämisessä tarvitaan paljon leveysriippuvaisia määrityksiä, sillä listaus ei ole taulukko vaan ul li muokataan ikään kuin taulukon näköiseksi.
Nyt pitäisi olla looginen.
Ensin yleinen
Sitten maksimi suurimmasta pienimpään. Jos on leveä näyttö, selain voi skipata kaikki @media screen and (max-width:...) lohkot. Kapeammilla näytöillä selain ottaa käyttöönsä sen mikä sopii.
Sitten minimit @media screen and (min-width...).. Kun nyt leveällä näytöllä edelliset kaikki skipattiin, vastaavasti nämä kaikki luetaan. Kapeammalla näytöllä lukeminen lopetaan tiettyyn kohtaan.
Lohkoissa tulee hyvin vähän uudestaan määritettävää ja se koskee kapeimpia näyttöjä. Uudelleen määritettävää on niin vähän, että laittanut kuin osalle min - max -välin. Sillä saisi pois kaiken uudelleen määrittämisen tarpeen.
Selaimen pitäisi lukea vähän yli puolet tiedostosta ja lähes puolet se voi skipata. Selaimen prosessoinnin näkökulmasta tiedoston koko on siten 30-40kB ja vaihtelee laitteesta riippuen. Olennaista on prosesoitava koko. Jos tässä mokaa, homma hidastuu.

Ei tilanne paljon muuttunut.
Etusivu > Foorumit 2,7s > Foorumi Suomen Kuvalehti 2,1s > SK pitkä säie 1,6s. Kun cachessa on tavaraa, keskimääräinen siirtymä on siis 2s.

Tein vastaavan testin tälle sivustolle:
Etusivu > Foorumit 2,1s > Foorumi Softakeskustelut 1,7s > Tämä säie 1,7s

Jos sivustoni foorumia haukutaan hitaaksi, tekemäni testin perusteella foorumin on VAIN n. 25% prosenttia hitaampi kuin tämä sivusto. Ei tässä mistään suuresta nopeuserosta ole kyse.

Kumpikin sivusto häviää nopeudessa mennen tullen itsetehdyille virityksille, joissa ei haeta JS:ää ja CSS:ää isoja määriä. Sanariksella on huono palvelin, mutta kevyt softa ja lopputulos on se, että se toimii kaikkein nopeiten.

Muilla kuin foorumisivuilla tyypillinen siirtymäaika on n. 1,5s. Foorumiosion CSS on kokonaan pois käytöstä, jos ei olla foorumiosiolla, joten Selain skippaa koko 75 kB CSS-tiedoston muilta sivuilta. Se on muilta sivuilta 40-50% pois, jos CSS ei olisi ehdollisena. Muilla sivuilla voi olla epäloogisuuksia, mutta tuskin tiputettavaa on 0,1s. enempää.
 
Viimeksi muokattu:
Ison näytön omaavat. Kelpaisiko tämä teille - en pienennyksestä osaa päätellä, miltä seuraava CSS käytännössä tuntuu:
Koodi: 
@media screen and (min-width:1601px){
.entry-content{width:70%;min-width:1000px!important; max-width:1500px;margin-left:auto;margin-right:auto;}
}
Mikä näissä WP-leiskoissa ärsyttää tietokoneella on hirvittävä levottomuus, jos vaihtaa leveyttä. WP-leiskoiille tyypillistä levottomuutta huomasin vielä otsikossa. Pääotsikko on joillakin leveyksillä hieman huonosti asemoitu. Pikkuseikka, joka pistää silmään. Vaikka ne on ajateltu tietyille mobiilileveyksille, tarpeeton uudelleen sijoittelu tms., joka WP-leiskoissa tapahtuu tietokoneella ikkunan levyttä vaihdettaessa on aika epämiellyttävää. Liikaa säätämistä leveyden mukaan. Tiedä häntä miten suuri ongelma yleisesti on ylisäätäminen.
 
Viimeksi muokattu:
Tapio X sanoi:
Jos sivustoni foorumia haukutaan hitaaksi, tekemäni testin perusteella foorumin on VAIN n. 25% prosenttia hitaampi kuin tämä sivusto. Ei tässä mistään suuresta nopeuserosta ole kyse.
Napsauta laajentaaksesi...
Älä vääristele. Sivuston lataus kesti vielä viime viikolla yli 5s ennen kuin selaimelle tarjottiin mitään sisältöä. Nyt näyttää toimivan ripeämmin.

Ulkoasuun, ikoneihin ja valikoiden käytettävyyteen jne en jaksa ottaa enää kantaa, mutta voisit korjata ainakin nuo kuvakkeet.

1620557384429.png


1620557537322.png


1620557575337.png
 
Noi näkyy minulla täysin oikein myös cachen tyhjennyksen jälkeen. Kuvakkeet on WordPressin vakiona asennettua ikonifonttia dashicons. Jostakin syystä selaimesi ei ole ladannut fonttia. Periaatteessa WordPress itse lataa fontin. Joskus kyllä jouduin tekemään sen, että laitoin CSS-tiedoston alkuun @font-face, kun vaimoin kännykällä fontti ei latautunut, vaikka se latautui tablet-laitteella ja tietokoneella. Näemmä ikonifonttien latautumisessa on joillakin selaimilla ongelmia. Sikäli ongelma on ikävä, että jos itsellä ei ole mitään ongelmia niiden latautumisessa, mutta toisilla on, en tiedä asiasta ennen kuin joku kertoo ongelmista. Joskus näkymistä haittasi väärät tiedoston lukuoikeudet. Ne korjattuani alkoi näkymään. Laitoin wp-content- hakemistoon ja alihakemistoon käyttöoikeusajon, jos se on siitä kiinni.

Sitä vaan ihmettelen, miksi tämä asia on laiteriippuvainen. Eikö puuttuminen pitäisi näkyä joka laitteessa. Onko sulla jokin erityisasetus, joka jotenkin blokkaa ikonifontteja. Niitä käytetään paljon WordPressin teemoissa ja itsekin niitä käytän lisäämässäni CSS:ssä kun ne kerran on asennettu.

Kautium sanoi:
. Sivuston lataus kesti vielä viime viikolla yli 5s ennen kuin selaimelle tarjottiin mitään sisältöä. Nyt näyttää toimivan ripeämmin.
Napsauta laajentaaksesi...
Kyse olikin tästä päivästä. Kun tänään tein vertailutestit, ero oli maintsemani. Sivusto vaihdettiin toiselle palvelimelle.
 
Viimeksi muokattu:
Täällä Microsoft Edgellä vaan laatikot näkyy noiden ikonien kohdalla. En tiedä minkälaiset ikonit siinä pitäisi näkyä.
 
Tapio X sanoi:
Noi näkyy minulla täysin oikein myös cachen tyhjennyksen jälkeen. Kuvakkeet on WordPressin vakiona asennettua ikonifonttia dashicons. Jostakin syystä selaimesi ei ole ladannut fonttia. Periaatteessa WordPress itse lataa fontin. Joskus kyllä jouduin tekemään sen, että laitoin CSS-tiedoston alkuun @font-face, kun vaimoin kännykällä fontti ei latautunut, vaikka se latautui tablet-laitteella ja tietokoneella. Näemmä ikonifonttien latautumisessa on joillakin selaimilla ongelmia. Sikäli ongelma on ikävä, että jos itsellä ei ole mitään ongelmia niiden latautumisessa, mutta toisilla on, en tiedä asiasta ennen kuin joku kertoo ongelmista. Joskus näkymistä haittasi väärät tiedoston lukuoikeudet. Ne korjattuani alkoi näkymään. Laitoin wp-content- hakemistoon ja alihakemistoon käyttöoikeusajon, jos se on siitä kiinni.

Sitä vaan ihmettelen, miksi tämä asia on laiteriippuvainen. Eikö puuttuminen pitäisi näkyä joka laitteessa. Onko sulla jokin erityisasetus, joka jotenkin blokkaa ikonifontteja. Niitä käytetään paljon WordPressin teemoissa ja itsekin niitä käytän lisäämässäni CSS:ssä kun ne kerran on asennettu.
Napsauta laajentaaksesi...
Tuosta samasta on kommentoitu sinulle muidenkin toimesta: WWW-sivujen kännyversiolle käyttöliittymä

Ei ole mitään erityisasetuksia, eikä ole väliä millä selaimella tai millä laitteella avaa, niin aina nuo kusevat samalla tavalla. En jaksanut tutkia koodia tarkemmin.

Tapio X sanoi:
Kyse olikin tästä päivästä. Kun tänään tein vertailutestit, ero oli maintsemani. Sivusto vaihdettiin toiselle palvelimelle.
Napsauta laajentaaksesi...
Niin, eikä sen jälkeen ole käsittääkseni valitettu hitaudesta ja tuo minun kommenttini oli vastine siihen väitteeseen.
 
Tämä dashicons-ongelma on kyllä outo, koska minulla ikonit näkyvät niinkuin pitääkin. Minulla näkyy seuraavan ikoniset ikonit kohdissa, joissa teillä ei näyl

developer.wordpress.org

Dashicons | Developer.WordPress.org

Dashicons is the official icon font of the WordPress admin as of 3.8. The Dashicons project is no longer accepting icon requests. Here's…
developer.wordpress.org developer.wordpress.org

En oikein ymmärrä tämänkaltaista käytöstä. Ne on määritelty ihan asiallisesti viitaten dashicons fonttin ja '\f123' -tyyliin käytettyyn ikoniin. Ei minulla noiden suhteen ole virheellistä koodia. Alla esimerkki. Tuon pitäisi näky ns. leivänmuruissa. Etusivulle on talo-ikoni.
Koodi: 
.bbp-breadcrumb-sep::before {
    content: '\f345';
    font: 400 15px/1 dashicons;
    position: relative;
    top: 2px;
}

Lisäsin @font-face-säännön alkuun ja laitoin selaimen hakemaan fontin relatiivista polkua käyttäen.
Koodi: 
@font-face {font-family: dashicons;url('/wordpress/wp-includes/fonts/dashicons.woff');}
Koska haetaan suoraan palvelimelta eikä kysytä netistä, pitäsi dashicons-ongelmien loppua. Tarkistin, että olin laittanut "dashicons" enkä "Dashicons" CSS-koodiini. Poistin tuon, kun ajattelin, ettei sitä tarvita kun fontti tuntuu latautuvan WordPressin lataamana.

Jäi joten ensimmäisen huomautuksen jälkeen tarttuminen ongelman selvittelyyn kun oli paljon suurempiakin ongelmia, pahoittelut. No osoittaa sen, että ikonifonttien kanssa voi tulla ongelmia muillekin kuin minulle. Kannattanee linkittää varmuuden vuoksi palvelimelle. Jos selain löytää asennetun fontin ja se pyydetään asentamaan toistamiseen, kai selain sen verran fiksu on, että se ei yritä toistamiseen fonttia ladata?
 
Viimeksi muokattu:
Oli syvemmällä tiedostolukuaoikeuksissa. Asetin koko hakemistorakenteelle tiedostolukuoikeudet uusiksi. Sen jälkeen toimi taas tablet-laitteella. Ei riittänyt, että muutin wp-includes ja siitä eteenpäin. Sitä @font-face... ei tarvita ja poistin sen. Tämä oli palvelimen vaihdon seuraus, jota ei tullut huomioitua. Ihmettelen kyllä, miksi tietokoneen selain ei reagoinut samalla tavalla vaan tuli ilmi minulla vain mobiililaitteessa.
 
Viimeksi muokattu:
Edelleen nuo dashiconsit kateissa. Ei näytä ainakaan minulla selain edes yrittävän ladata tuota fonttia mistään ja sen takia käyttää fallbackina jotain serif-perheen fonttia. Monserrat- ja Roboto-fontteja kyllä ladataan pariinkin kertaan googlen suunnalta.
 
Koska itse sain tablet-laitteeseen dashicons-fontin, kokeile välimuistin tyhjennystä. Tyhjensin laitteesta sen ennen uutta kokeilua. Minulla oli fontti kateissa mutta ei ole enää. Sinänsä hankalia nuo.

Kirjoitin aiemmin:
Etusivu > Foorumit 2,7s > Foorumi Suomen Kuvalehti 2,1s > SK pitkä säie 1,6s. Kun cachessa on tavaraa, keskimääräinen siirtymä on siis 2s.

Tein vastaavan testin tälle sivustolle:
Etusivu > Foorumit 2,1s > Foorumi Softakeskustelut 1,7s > Tämä säie 1,7s
Napsauta laajentaaksesi...

Minulla olisi vielä yksi kikka kolmonen, jolla saan siirtymät foorumilistauksissa säännöllisesti 1,7 sek eikä se juuri vaihtele. Kikka vaatii vähän vielä hiomista ja se edellyttää, että levys vaihtuu portaittain tarkka pikselimäärä antaen. Mitään max ja min välinen eläminen ei käy päinsä. Pitää käydä listat lävitse, että tulee joka listaan.

Yksittäisen säikeen kohdalla kikkaa ei voi käyttää. Se pitäisi sulkea pois käytöstä.

Viitsiikö 0,3-04s sek. säästöön ruveta?
 
Viimeksi muokattu:
Joo ei tässä kyllä mistään palveluntarjoajan vaihtamisesta ole kyse. Ei ole ainakaan täällä päässä toiminut millään laitteella lähiaikoina nuo ikonit.

Nyt kun optimoinnin kanssa jumppaat, niin katsohan jatkossa noita aikoja vaikka googlen lighthousella sekunttikellon sijaan. Se jopa antaa vinkkejä miten saat sivujen latausta nopeutettua.
 
Lataa nuo fontit suoraan omalle palvelimelle ja määrittele ne oikein css:ään niin sat niistä nipistettyä helpolla muutaman sekunnin osan, niinkuin edelleenkin olen maininnut niin nuo gstaticista fonttien hakemiset tuntuvat jostain syystä olevan hitaita. Ja tosiaan, sen verran kurkkasin tuota koodia että eihän siellä missään ole määritelty mistä nuo dashiconsit pitäisi löytyä niin eihän ne voi kenelläkään toimia ellei satu jostain muusta syystä löytymään koneelta.
 
Hyrava sanoi:
Lataa nuo fontit suoraan omalle palvelimelle ja määrittele ne oikein css:ään niin sat niistä nipistettyä helpolla muutaman sekunnin osan, niinkuin edelleenkin olen maininnut niin nuo gstaticista fonttien hakemiset tuntuvat jostain syystä olevan hitaita. Ja tosiaan, sen verran kurkkasin tuota koodia että eihän siellä missään ole määritelty mistä nuo dashiconsit pitäisi löytyä niin eihän ne voi kenelläkään toimia ellei satu jostain muusta syystä löytymään koneelta.
Napsauta laajentaaksesi...
Koodi: 
<link rel='stylesheet' id='dashicons-css'  href='https://www.sanaristikkofoorumi.net/wordpress/wp-includes/css/dashicons.min.css?ver=5.7.1' type='text/css' media='all' />

// tiedoston alku
@font-face{font-family:dashicons;src:url("../fonts/dashicons.eot?99ac726223c749443b642ce33df8b800");src:url("../fonts/dashicons.eot?99ac726223c749443b642ce33df8b800#iefix") format("embedded-opentype"),url("data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAHvwAAsAAAAA3EgAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABHU1VCAAABCAAAADMAAABCsP6z7U9TLzIAAAE8AAAAQAAAAFZAuk8lY21hcAAAAXwAAAk/AAAU9l+BPsxnbHlmAAAKvAAAYwIAAKlAcWTMRWhlYWQAAG3AAAAALwAAADYXkmaRaGhlYQAAbfAAAAAfAAAAJAQ3A0hobXR4AABuEAAAACUAAAVQpgT/9mxv
Ne on palvelimella. Asensin WP:n uudelleen. Toimii puolessa perheen laitteissa edelleen. En ymmärrä, mikä mättää.
 
tomnav sanoi:
Nyt kun optimoinnin kanssa jumppaat, niin katsohan jatkossa noita aikoja vaikka googlen lighthousella sekunttikellon sijaan. Se jopa antaa vinkkejä miten saat sivujen latausta nopeutettua.
Napsauta laajentaaksesi...
Kun laitoin sillä testin päälle, se kävi tietyn määrän sivuja lävitse. En löytänyt siitä yksittäisen siirtymän tietojen tarkkailemista. Sekunttari on kyllä ihan riittävän tarkka. Se antaa suuntaa antavan lukeman.

Se 1,7s siirtyminen foorumiosiosta toiseen on siis pienin aika, jota palvelimella ja sopivalla CSS:llä on mahdollista. En ota sitä minimiajan mahdollistajaa käyttööni nyt,koska ensin pitää katsoa nykyiset leveydet ja sen jälkeen niille pitää antaa järkevät portaat ja määrittää porrasvälit. Kuka arvaa, millä kikalla saa muutaman kymmenyksen vähennettyä erilaisten listojen latausajoista. Ajattelin, että ero olisi suurempikin.

Teema käyttää toista ikonisettiä. Jos sitä käyttää, kaikki nykyiset \f... pitäisi määrittää uusiksi ja korvata fontin nimi sillä toisella. Oli joskus sama ongelma, mutta se hävisi. Hiivatti kun fonteista tuli nyt suurin ongelma.
 
Viimeksi muokattu:
Hyvinhän tuo sun foorumisi tällä hetkellä ainakin itselläni aavistuksen päälle sekunnissa latailee sivuja, jotain 1.1-1.4s luokkaa näyttää inspector josta 0.8s tulee edelleen siitä ensimmäisestä html-requestista. Alkaa olla nopeuden puolesta jo jopa melkein iobbs:n luokkaa. Mutta tosiaan edelleen dashicons on rikki ja kaikenlaista muuta vastaavaa on vähän siellä sun täällä.
 
Ne muut on ihan pikku juttuja. Voit toki ne eritellä, niin fiksailen kun jaksan. Minulla on kyllä lista mitä pitää muutella, mutta ei siinä tällä hetkellä montaa kohtaa ole .Jostakin tuli taas yksi ylimääräinen alaviiva, mutta se ei ole huomiota herättävä.

Pitäisi kaikilla leveyksillä käyttäytyä siististi eikä tietokoneella kavennettaessa käyttäydy kovinkaan levottomasti. Kun tehdään eri laitteille, pientä poukkoilua tulee. Yksi leveysalue saisi olla vähän leveämpi, mutta mikään erityisen kapea sivu ei millään leveysalueella ole.
 
Viimeksi muokattu:
Tietokoneelta loppui kirjautumisaika. Dashicons-setti hävisi. Näin siis Dashicons-setin laitteilla, joille olin kirjautunut, mutta en niillä, joihin en ollut kirjautunut. En nyt ymmärrä. mikä blokkaa setin kirjautumattomilta henkilöiltä. @font-face ei millään asetuksella toimi.

V*** niin p***, jos homma nyt tähän kaatuu.
 
Viimeksi muokattu:
Tapio X sanoi:
Tietokoneelta loppui kirjautumisaika. Dashicons-setti hävisi. Näin siis Dashicons-setin laitteilla, joille olin kirjautunut, mutta en niillä, joihin en ollut kirjautunut. En nyt ymmärrä. mikä blokkaa setin kirjautumattomilta henkilöiltä. @font-face ei millään asetuksella toimi.

V*** niin p***, jos homma nyt tähän kaatuu.
Napsauta laajentaaksesi...

Koklaa vaihtaa:
Koodi: 
@font-face {font-family: dashicons;url('/wordpress/wp-includes/fonts/dashicons.woff');}
muotoon:
Koodi: 
@font-face {font-family: dashicons;src:url('/wordpress/wp-includes/fonts/dashicons.woff');}
 
Kiitti. Tuo esittämäsi koodi toimii. Huolimatonta lukemista, sillä tuohon tapaan koodiesimerkki oli W3C:n sivuilla. Kun kirjautuneet ei tuota tarvitse, pistin ehtolauseen.
Koodi: 
if(!is_user_logged_in()){
$notLoggedInCSS='<style>
@font-face {font-family: dashicons;src:url(\'/wordpress/wp-includes/fonts/dashicons.woff2\');}
</style>';
}
Tämä oli kyllä oudoin tapaus niistä kaikista oudoista asioita joita olen kohdannut sen suhteen, miten kirjautuminen muuttaa sivujen käytöstä. Tulipa ratkaistua sentään. Mitenkähän joku WP-guru selittäisi tämän?

PS. Huvitti tuo TMC:n avatar.
 
Viimeksi muokattu:
Seuraavaksi pitäisi saada määritettyä sivustolle Google Captcha ver. 3., mutta en vain yrityksistä huolimatta löydä ohjeita enkä sivua, missä operaatio tehdään. Olisi aika päivittää olemassa oleva v2 invisible v. 3:een olemassa olevalle lisäosalle ja koko sivustolle.
 
Pieni hidaste on Googlen seurantakoodi. Vaikka ei omalla sivustolla olisi lisäosana Googlen analytiikkaa, sitä tarvitaan myös silloin, kun haluaa seurata sivuston statistiikka Googlen sivujen analyysitoiminnan kautta. Jos se poistaa, ei sitten analytiikka toimi Googlen sivujenkaan kautta.

Laitoin Googlen tarvitseman JS:n omaksi CodeSnippet-tietueekseen. Sen saa helposti päälle ja pois päältä. Analyytikkaa voi siten käyttää periodeittain, ei koko ajan. Minulla ei nyt kylläkään ole kuvaa, miten paljon Googlen analytiikan mukana olo hidastaa sivujen latautumista. Osaako joku kertoa asiasta?
 
Jospa ihan itse katselisit noita jollakin inspectorilla, työkalut kuitenkin ovat ihan ilmaiseksi kaikkien saatavilla. Esim firefoxin sisäänrakennetulla inspectorillakin näkee jo paljon mikä sivuilla hidastelee, mitä virheitä siellä on, mitä tiedostoja ei löydy jne. Ja sillä voi vaikka lennosta kokeilla erilaisia pikkumuutoksia ettei koko sivun koodiin edes tarvitse koskea.
 
Aattelin vaan, että jollakulla on tuntuma siitä, mikä on Googlen analytiikan mukanaolon mekitys nopeuden kannalta. En minä sivujani ketään tarkastelemaan pyytänyt vaan pyysin vain jakamaa kokemuksia asiasta. Vaikuttaa siltä, että se ei mitenkään havaittavasti vaikuta latautumiseen, joten sen voi pitää päällä.
 
Viimeksi muokattu:
Tarvitaanko samankaltaiselle aiheelle kahta ketjua? Äkkiseltään selailtuna myös toisesta aloittajan ketjusta löytyy ihan vastaavankaltaista keskustelua, joka ei suoranaisesti liity tiiviisti ketjun otsikkoon:

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

Otin tämän aiheen erikseen, koska se on tärkeä. Merkittävä osa www-sivuilla vierailuista tapahtuu kännykällä. Kännykkää pidetään www-sivuja selattaessa pääsääntöisesti pystysuunnassa. Pystysuunnassa kännykässä on pitkä oikea reuna, jonka hyödynsin käyttöliittymänä: Aihe: Sivuston mobiiliversio...
bbs.io-tech.fi
Jotain syytä, miksei näitä ketjuja yhdistettäisi? @Tapio X
 
Viimeksi muokattu:
Juha Kokkonen sanoi:
Jotain syytä, miksei näitä ketjuja yhdistettäisi?
Napsauta laajentaaksesi...
Jos minulta kysytään niin ei ole, eli yhteen vaan.

Jos kyse olisi oikeasti yleisestä WP-ketjusta niin tälle voisi olla jotain tarvetta, mutta tämä koskee pelkästään aloittajan omaa sivustoa, kuten se toinenkin ketju. Jos tarvetta ilmenee, niin dedikoidun WP-ketjun voi perustaa myöhemmin kattavammalla aloituksella uudestaan.
 
Kuten aiemmin selitin, tästä ei ollut alunalkaen tullu sellainen kuin tuli. Ja pitkän käsittelyn vuoksi on hyvä, että tämä on omana ketjuna eikä osa omien kotisivujen kehittelyn yleissäiettä.

Tämän säikeen ja seuraavan säikeen voisi ihan hyvin yhdistää:

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

Otin tämän aiheen erikseen, koska se on tärkeä. Merkittävä osa www-sivuilla vierailuista tapahtuu kännykällä. Kännykkää pidetään www-sivuja selattaessa pääsääntöisesti pystysuunnassa. Pystysuunnassa kännykässä on pitkä oikea reuna, jonka hyödynsin käyttöliittymänä: Aihe: Sivuston mobiiliversio...
bbs.io-tech.fi

Katium on täysin oikeassa tässä:
Jos kyse olisi oikeasti yleisestä WP-ketjusta niin tälle voisi olla jotain tarvetta, mutta tämä koskee pelkästään aloittajan omaa sivustoa, kuten se toinenkin ketju. Jos tarvetta ilmenee, niin dedikoidun WP-ketjun voi perustaa myöhemmin kattavammalla aloituksella uudestaan.
Napsauta laajentaaksesi...

Itse asiassa olen täysin samaa mieltä. Siitä ei tullut yleinen WP-ketju. Jos joku kysyy omaan nettisivuprojektiinsa WP-kikkoja, voi niitä jakaa muillekin. Kzikki kikat, joilla voi laajentaa WP:tä ilman, että luo lisäosaa, ovat tulleet tutuksi.
 
Viimeksi muokattu:
Juha Kokkonen sanoi:
Tarvitaanko samankaltaiselle aiheelle kahta ketjua? Äkkiseltään selailtuna myös toisesta aloittajan ketjusta löytyy ihan vastaavankaltaista keskustelua, joka ei suoranaisesti liity tiiviisti ketjun otsikkoon:

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

Otin tämän aiheen erikseen, koska se on tärkeä. Merkittävä osa www-sivuilla vierailuista tapahtuu kännykällä. Kännykkää pidetään www-sivuja selattaessa pääsääntöisesti pystysuunnassa. Pystysuunnassa kännykässä on pitkä oikea reuna, jonka hyödynsin käyttöliittymänä: Aihe: Sivuston mobiiliversio...
bbs.io-tech.fi
Jotain syytä, miksei näitä ketjuja yhdistettäisi? @Tapio X
Napsauta laajentaaksesi...
29.4 olitte ainakin sitä mieltä että tarvitaan kaksi ketjua kun silloin on pyydetty näiden ketjujen yhdistämistä.

Edit. Toki silloin ei ehkä ollut vielä niin hyvin tiedossa että mihin raiteilla ketju sitten lähtee loppujen lopuksi. Minusta tämän ketjun keskustelu ei juurikaan eroja tuosta toisesta.
 
Nightuser sanoi:
29.4 olitte ainakin sitä mieltä että tarvitaan kaksi ketjua kun silloin on pyydetty näiden ketjujen yhdistämistä.
Napsauta laajentaaksesi...
Juu, no silloin ei oikein ollut vielä selvyyttä mitä sisältö tulee olemaan. Jos tämä ketju olisi muodostunut yleismalliseksi, niin tilanne olisi eri. Nyt tämä vaikuttaisi olevan pääosin joku epämääräinen oman projektin läpikäyntiketju
 
Juha Kokkonen sanoi:
Juu, no silloin ei oikein ollut vielä selvyyttä mitä sisältö tulee olemaan. Jos tämä ketju olisi muodostunut yleismalliseksi, niin tilanne olisi eri. Nyt tämä vaikuttaisi olevan pääosin joku epämääräinen oman projektin läpikäyntiketju
Napsauta laajentaaksesi...
Juu niin aivan. Hitto kerkesin just editoimaan aiempaan viestiä. En tiedä kerkesitkö näkemään.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
258 735
Viestejä
4 497 036
Jäsenet
74 275
Uusin jäsen
rillo

Hinta.fi

Back
Ylös Bottom