Website is traag. Host zegt door video in 'loop'?

[Stab]

Ik heb meerdere websites online staan (draaiend op Wordpress) en allemaal zijn ze razendsnel,behalve één daarvan.

Ik heb onlangs een nieuw thema geïnstalleerd en alles nog eens flink geoptimaliseerd en nu scoort de website vrij goed op PageSpeed en op GtMetrix krijgt hij zelfs een 94/100. De website is maar 800kb in grootte en zou gewoon razendsnel moeten aanvoelen. Het grappige is dat één van mijn andere websites totaal niet is geoptimaliseerd, vele malen groter is en nog meer plug-ins gebruikt, instant open is in mijn browser. De trage website duurt soms wel 10-15 seconden om te verschijnen op mijn scherm... Dit is niet terug te vinden in de diagnostic tools die aangeven dat hij snel laadt en in 5 seconden helemaal geladen is.
Ook zit er veel verschil in hoe snel hij laadt op verschillende tijdstippen.

Mijn host gecontacteerd en die zegt dat ze zien dat er een video van 30 mb wordt geladen en op het moment dat die is geladen, wordt hij opnieuw geladen. Ofwel, ze zien een 'loop' in het laden hiervan.

Nou heb ik inderdaad een aantal Vimeo Embeds op de website staan, verdeeld over meerdere pagina's. Zou dat het kunnen zijn dan? Dat is ook het enige verschil namelijk met de andere websites...

De video's zijn wel van essentieel belang dus hoe zou ik dat dan eventueel anders kunnen aanpakken?
Weet iemand wat de host bedoelt? En wat zou ik hier eventueel aan kunnen doen?

Dit is de website:
http://www.cinematicwedding.nl

De initiële load duurt meestal dus erg lang. Als je eenmaal op de pagina zit, dan openen de subpagina's vrij rap.
Als iemand een idee heeft hoor ik het graag!!

[André]

Je zou de video ook pas in kunnen laden wanneer hij in zicht komt? Of gewoon achter een "play" knop? Dit kun je mensen die met een mobieltje komen bijna niet aandoen, daar vreet je onnodig dikke mb's op. Het trekt je verbinding ook redelijk dicht op deze manier.

Daarnaast zie ik nog wel meer ruimte voor verbetering: 50 javascript bestanden en 28 CSS bestanden. Als je die zou vervangen door 2 scripts (1 benodigde en 1 die onderaan kan) en 1 CSS ben je al 75 HTTP connecties kwijt.

[ Voor 29% gewijzigd door André op 07-10-2015 13:37 ]

[jbdeiman]

Je zou misschien je video's via YouTube + YouTube api in kunnen laden ipv via Vimeo? Dit moet zelfs kunnen met een "gesloten" youtube account, dus de "niet openbare video's".

Zoekend op slow website with Vimeo video's dan kom ik redelijk wat resultaten tegen, maar eigenlijk nooit een echte oplossing.

Je kan je Hoster ook eens vragen of het echt elke keer om dezelfde video gaat, want dat zou dan wel een probleem zijn. Gebruik je een addblocker? Die schijnen dat effect ook wel eens te hebben op van die Vimeo video's.

Verder weet ik niet wat voor opties je hebt bij het aanmaken van Embed code, als je een gewoon account hebt, maar bij een Pro account schijn je meer opties te hebben.

[Stab]

André schreef op woensdag 07 oktober 2015 @ 13:35:
Je zou de video ook pas in kunnen laden wanneer hij in zicht komt? Of gewoon achter een "play" knop? Dit kun je mensen die met een mobieltje komen bijna niet aandoen, daar vreet je onnodig dikke mb's op. Het trekt je verbinding ook redelijk dicht op deze manier.

Daarnaast zie ik nog wel meer ruimte voor verbetering: 50 javascript bestanden en 28 CSS bestanden. Als je die zou vervangen door 2 scripts (1 benodigde en 1 die onderaan kan) en 1 CSS ben je al 75 HTTP connecties kwijt.

Thanks!
Het kan in mijn ogen niet de video zijn die op de homepage staat om twee redenen:

- Op mijn 'oude' website (theme) had ik die video niet en had toen al heel lang dit zelfde probleem
- Op mobiel laadt deze video niet, maar is hij vervangen door een plaatje van 20kb

Het ligt denk ik dan eerder aan de embedded video's (met een playknop!) op de overige pagina's...

Ik heb onvoldoende kennis om die javascripts en CSS bestanden te combineren. Ik kan wel de geoptimaliseerde bestanden van Google downloaden, maar ik vrees dat dan de website niet meer goed werkt... Iemand daar ervaring mee?

[André]

Wat zijn dan de laadtijden die je in je analytics account ziet? En dan voornamelijk de server response, DOM interactive time en de page load time? En op basis van hoeveel metingen is dat?

[marcop23]

Bij mij was er wel één bestand verantwoordelijk voor heel veel data, ik heb hem een paar minuten aan laten staan en jouw site heeft 220MB verstookt.

[Stab]

jbdeiman schreef op woensdag 07 oktober 2015 @ 13:51:
Je zou misschien je video's via YouTube + YouTube api in kunnen laden ipv via Vimeo? Dit moet zelfs kunnen met een "gesloten" youtube account, dus de "niet openbare video's".

Zoekend op slow website with Vimeo video's dan kom ik redelijk wat resultaten tegen, maar eigenlijk nooit een echte oplossing.

Je kan je Hoster ook eens vragen of het echt elke keer om dezelfde video gaat, want dat zou dan wel een probleem zijn. Gebruik je een addblocker? Die schijnen dat effect ook wel eens te hebben op van die Vimeo video's.

Verder weet ik niet wat voor opties je hebt bij het aanmaken van Embed code, als je een gewoon account hebt, maar bij een Pro account schijn je meer opties te hebben.

Thanks!
Ik heb een Plus account dus heb wel degelijk wat opties, maar alle video's op de website zitten gewoon achter een playknop en hoeven dus niet helemaal geladen te worden.
Wellicht moet de website bezoeker wel wachten tot de plaatjes van Vimeo worden geladen en de bestanden worden opgehaald, dat zou ik nog wel enigzins kunnen geloven.

Het probleem is alleen, waarom worden al deze video's geladen terwijl ze niet op de homepage staan? Die zitten namelijk op de andere subpagina's... De video op de homepage kan het probleem niet zijn omdat ik dit probleem ook al had voordat ik die er in heb gezet.

[Stab]

André schreef op woensdag 07 oktober 2015 @ 13:54:
Wat zijn dan de laadtijden die je in je analytics account ziet? En dan voornamelijk de server response, DOM interactive time en de page load time? En op basis van hoeveel metingen is dat?

In Pagespeed Insights ligt de Server Reponse Time altijd zo rond de 1 tot 1.5 seconde. Soms met uitschieters naar boven. Daar heb ik al eerder over geklaagd bij de host maar die zegt dat het niet aan hen ligt.

Aangezien mijn andere websites nog veel minder geoptimaliseerde theme's draaien en ik dit probleem nu bij deze website bij 2 verschillende themes heb gehad, lijkt het me dan toch te moeten liggen aan de Vimeo filmpjes.

Bijna elke subpagina heeft namelijk 3 embedded video's. Weliswaar achter een playknop, maar ik denk dat dit toch wel eens de reden kan zijn.

[Stab]

marcop23 schreef op woensdag 07 oktober 2015 @ 13:55:
Bij mij was er wel één bestand verantwoordelijk voor heel veel data, ik heb hem een paar minuten aan laten staan en jouw site heeft 220MB verstookt.

Hi.
Dat is dan waarschijnlijk de video op de homepage die 'autoplay' heeft aanstaan. Overigens is dit op mobiel uitgeschakeld en is de video dan vervangen door een plaatje.

Dit moet echter niet veel invloed hebben op de laadtijden van de website lijkt me, omdat als de video te traag buffered die gewoon gaat haperen in het ergste geval. Lijkt mij dan.

[borft]

Holy crap, als ik die pagina laad, doet mijn browser 122 requests... hierdoor duurt het 7 seconden voor de pagina klaar is.

Ik zou toch echt es gaan kijken naar het combineren en minifyen van die files....

[André]

Stab schreef op woensdag 07 oktober 2015 @ 13:57:
[...]


In Pagespeed Insights ligt de Server Reponse Time altijd zo rond de 1 tot 1.5 seconde. Soms met uitschieters naar boven. Daar heb ik al eerder over geklaagd bij de host maar die zegt dat het niet aan hen ligt.

Nee, niet Pagespeed Insights, dat is een n=1 meting, Google Analytics heeft veel meer metingen (standaard bij 1% van je bezoekers) en geeft een beter beeld.

[Stab]

André schreef op woensdag 07 oktober 2015 @ 14:03:
[...]

Nee, niet Pagespeed Insights, dat is een n=1 meting, Google Analytics heeft veel meer metingen (standaard bij 1% van je bezoekers) en geeft een beter beeld.

Average Page load time = 5.44 sec
Average Server Response Time = 3.40 sec

De homepage is het traagst met average 8.9 sec... Maar dat wisten we al

[ Voor 9% gewijzigd door Stab op 07-10-2015 14:07 ]

[simon]

Volgens mij ligt het niet aan de content van je site, als ik in de Network Inspector van Chrome kijk zie ik dat het request aan de / of index.php zo'n 8 seconden duurt. De rest van de requests, en dan met name de statische requests zijn relatief snel.

Het kan zijn dat je een crappy plugin gebruikt, die onhandig met queries aan de gang is, of andere crap. Maar het request op de index is gewoon 't sloomste. Desnoods profilen?

[André]

Stab schreef op woensdag 07 oktober 2015 @ 14:07:
[...]


Average Page load time = 5.44 sec
Average Server Response Time = 3.40 sec

Dan zit er duidelijk al iets mis op de server. Die zou er max 300ms over mogen doen. Heb je een caching module aan staan?

[Stab]

simon schreef op woensdag 07 oktober 2015 @ 14:07:
Volgens mij ligt het niet aan de content van je site, als ik in de Network Inspector van Chrome kijk zie ik dat het request aan de / of index.php zo'n 8 seconden duurt. De rest van de requests, en dan met name de statische requests zijn relatief snel.

Het kan zijn dat je een crappy plugin gebruikt, die onhandig met queries aan de gang is, of andere crap. Maar het request op de index is gewoon 't sloomste. Desnoods profilen?

Ik denk ook dat die overige statische scripts niet het probleem zijn. Ik heb websites met net zoveel scripts en die openen instant op gewoon een prima internetverbinding. De afbeeldingen zijn allemaal geoptimaliseerd en extreem klein.
Ik denk zelf dat het niet anders kan eigenlijk dan dat het de embedded vimeo video's zijn. Dat we op de server van vimeo moeten wachten tot dat de thumbnails geladen zijn ofzo.

Qua plug-ins kan ik anders niks verzinnen. Het zijn allemaal dezelfde plug-ins als bij mijn andere website die instant opent in mijn browser. Alleen de price-table plug-in is extra. Ik denk niet dat die het is eerlijk gezegd.

Wat is profilen precies?

[Stab]

André schreef op woensdag 07 oktober 2015 @ 14:08:
[...]

Dan zit er duidelijk al iets mis op de server. Die zou er max 300ms over mogen doen. Heb je een caching module aan staan?

Ik heb een Leverage Browser Caching plug-in draaiende, ik weet niet of je dat bedoelt. Verder een plug-in genaamd BJ Lazy Load die er voor zorgt dat dingen boven aan de pagina eerder worden geladen zodat we niet hoeven te wachten op wat daar onder staat. Aan of uit bij beide plug-ins maakt weinig verschil in de praktijk.

Het is denk ik dus niet de server van mijn host, want daar heb ik ook al 50 keer voor gebeld en over gemaild, maar eerder de server van Vimeo misschien? Ik denk dat we moeten wachten tot de vimeo thumnails zijn geladen van hun server.

De embedded video's van de subpagina's worden toch ook al geladen als je de homepage laadt, toch?

[André]

De Vimeo video's worden pas clientside ingeladen, dat staat helemaal los van de trage server respons tijd.

[Stab]

André schreef op woensdag 07 oktober 2015 @ 14:15:
De Vimeo video's worden pas clientside ingeladen, dat staat helemaal los van de trage server respons tijd.

Oke, dan is de server wellicht wat langzamer dan hij zou moeten, maar de website laadt in de praktijk nog veel langzamer dan de SRT doet vermoeden.

Het duurt 9-15 seconden voordat de website op mijn scherm verschijnt en de SRT is maar 1-3 seconden.
Ik ben nu meer aan het lezen over embedded video's en hoe dat een effect kan hebben op de langzame laadtijden van de website.

Er is een plug-in (lazy load for video's) die ik zo eens ga proberen. Doet dat niks, dan kan ik eens proberen alle vimeo's even te verwijderen, kijken of dat verschil maakt. Een hoop gedoe, maar dan weet ik het ook zeker.

[Meekoh]

het lijkt ook wel alsof die fonts erg vaak geladen/applied worden. Zodra ik de homepage open zie ik eerst de tekst 11 keer van font veranderen en verspringen

[Stab]

Ik heb nu een plug-in geinstalleerd die heet Lazy Load for Video.

Ik zie geen verschil in hoe het eruit ziet, maar ik moet zeggen dat het wel een stukje sneller aanvoelt nu.
Iemand die de website al gezien heeft die het verschil ook ziet? Waar kan ik dat nou echt goed testen? Want op PageSpeed / GTMetrix scoorde de website sowieso al heel goed.

Maar het moet in ieder geval nog een stuk sneller kunnen.

[ Voor 9% gewijzigd door Stab op 07-10-2015 14:43 ]

[simon]

Nee, maar zoals ik al eerder zei, er is niets aan de hand na de initiele load, er is ergens in je index.php / whatever WordPress doet iets wat 'm bijzonder vertraagt. Het is een WP plugin, of iets dergelijks, crappy config van je hoster, iets in die hoek. Je kan het eindeloos zoeken in andere dingen, maar als je de Network inspector

(dit ding)

er even bij pakt, en goed kijkt naar de oorzaak van de traagheid.

Je kan bijvoorbeeld met een tool als New Relic, of lokaal profilen, kijken naar wat er aan de hand is met je pagina, of er specifieke code blokken sloom zijn, de PHP config crappy, de server gewoon sloom, etc.

Lees ook https://developer.chrome.com/devtools/docs/network eens door. Dan snap je wat er daadwerkelijk gebeurt.

[borft]

Als ik alleen de index ophaal:
$ time wget -O /dev/null http://www.cinematicwedding.nl
--2015-10-07 14:42:01-- http://www.cinematicwedding.nl/
Resolving www.cinematicwedding.nl (www.cinematicwedding.nl)... 109.235.74.40
Connecting to www.cinematicwedding.nl (www.cinematicwedding.nl)|109.235.74.40|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/null’

/dev/null [ <=> ] 54.63K --.-KB/s in 0.07s

2015-10-07 14:42:04 (796 KB/s) - ‘/dev/null’ saved [55945]


real 0m2.720s
user 0m0.000s
sys 0m0.000s

oftewel, bijna 3 seconden voordat uberhaupt de index pagina binnen is.....

[Stab]

borft schreef op woensdag 07 oktober 2015 @ 14:42:
Als ik alleen de index ophaal:
$ time wget -O /dev/null http://www.cinematicwedding.nl
--2015-10-07 14:42:01-- http://www.cinematicwedding.nl/
Resolving www.cinematicwedding.nl (www.cinematicwedding.nl)... 109.235.74.40
Connecting to www.cinematicwedding.nl (www.cinematicwedding.nl)|109.235.74.40|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/null’

/dev/null [ <=> ] 54.63K --.-KB/s in 0.07s

2015-10-07 14:42:04 (796 KB/s) - ‘/dev/null’ saved \[55945]


real 0m2.720s
user 0m0.000s
sys 0m0.000s

oftewel, bijna 3 seconden voordat uberhaupt de index pagina binnen is.....

Maar worden de embedded video's op de homepage + subpagina's daarin nou alvast wel of niet voor geladen? En plug-ins zoals de pricing table op de subpagina 'prijzen'?
Of omvat dit alleen de scripts en content van de homepage zelf?

[Meekoh]

Stab schreef op woensdag 07 oktober 2015 @ 14:47:
[...]


Maar worden de embedded video's op de homepage + subpagina's daarin nou alvast wel of niet voor geladen? En plug-ins zoals de pricing table op de subpagina 'prijzen'?
Of omvat dit alleen de scripts en content van de homepage zelf?

Nee de video's zitten daar als het goed is niet in. Die worden zo te zien asyncrhoon erin gefietst.

[simon]

Kijk, achter die / of index.php zit 1 script, die genereert HTML, die HTML komt dus na een paar seconden bij je browser binnen, en dan gaat die 't parsen, en dan komt al die andere requests.

Volgens mij moet je die link die ik er bij heb gezet gewoon even lezen, dan snap je sneller de principes, want anders leggen we allemaal uit waar je naar moet kijken maar komt 't totaal niet over.

[borft]

stab: die wget van mij haalt alleen de index op, die 3 seconden is dus alleen wordpress, er wordt niets gerenderd, er wordt verder niets opgehaald, geen css, geen js, geen video's niets. Het is puur de tijd van index.php, oftewel wordpress.

[Stab]

borft schreef op woensdag 07 oktober 2015 @ 14:54:
stab: die wget van mij haalt alleen de index op, die 3 seconden is dus alleen wordpress, er wordt niets gerenderd, er wordt verder niets opgehaald, geen css, geen js, geen video's niets. Het is puur de tijd van index.php, oftewel wordpress.

Vreemd. Hoe kan het dan dat een andere site die ik heb, die ook op Wordpress draait met een vergelijkbaar aantal plug-ins, wel razendsnel laden, ondanks slechte optimalisatie?

Even in Jip en Janneke-taal, wat kan ik er zelf dan nog aan doen? Dit is nu al het 2e theme wat ik heb geprobeerd en de slechte laadtijden blijven en zijn hetzelfde. Het ligt dus niet aan het theme wat ik heb. Ik heb alle plug-ins al eens uitgezet om te kijken of het verschil maakt, maar dat maakt het ook niet.

Dus wat kan het dan nog zijn? Is mijn database ergens 'corrupt' geraakt ofzo? Moet ik nog proberen om een geheel nieuwe installatie te doen (met alle gevolgen van dien?)

Ik heb alleen nog niet geprobeerd alle embedded video's te verwijderen maar volgens jullie ligt het hier dan ook niet aan...

Dan moet ik er wellicht maar eens een professional naar laten kijken ofzo. Ik heb niet de kennis om het hele theme nog eens te gaan rewriten. Alle Mickey Mouse methoden heb ik nu wel zo'n beetje geprobeerd.

[André]

Je zou het eens met een goed ingestelde W3 Total cache (plugin) kunnen proberen. Mocht er dan nog iets niet lekker gaan op de server zou je nog kunnen overwegen de gratis variant van CloudFlare voor je site te zetten.

[Stab]

André schreef op woensdag 07 oktober 2015 @ 23:03:
Je zou het eens met een goed ingestelde W3 Total cache (plugin) kunnen proberen. Mocht er dan nog iets niet lekker gaan op de server zou je nog kunnen overwegen de gratis variant van CloudFlare voor je site te zetten.

Thanks. Ik heb zojuist W3 Total Cache geïnstalleerd en even wat standaard instellingen toegepast die ik las op internet.
Heeft me sowieso al 5 punten opgeleverd in Google Pagespeed. Van 84 naar 89/100. Sowieso positief dus!

Toch voelt de website nog steeds traag. In ieder geval niet heel veel sneller. Behalve nog wat combineren van javascripts en CSS bestanden valt er denk ik niet zo heel veel meer te optimaliseren.

Het is dus óf de video's, óf toch een server/database probleem. Host zegt dat het niet aan de server ligt, dus dan blijven voor mij die andere twee opties over.
Ik zal morgen eens proberen alle embedded video's te verwijderen, kijken of dat het verschil maakt.
Will report here.

[Stab]

Bonusvraag:

Als ik de website MET www test in PageSpeed dan zeurt hij vanaf nu niet meer over de Server reponse time. Die is dus blijkbaar nu 'goed' volgens Pagespeed en ik scoor ook hoger dan ooit. Heeft de W3 total cache dus aan mee geholpen in ieder geval.

Maar als ik 'www' weg laat en dan de Pagespeed check, scoor ik een paar punten lager en geeft hij aan dat de server reponse time 1.1 seconde is.

- Hoe kan dit? Ik heb volgens mij nergens een redirect staan. In ieder geval niet in htaccess.
- Zou dit met 'het probleem' te maken kunnen hebben? Dat er ergens een infinite loop van redirects bestaat ofzo?

[RobIII]

Als je nou eens gewoon op F12 mept en zélf gaat kijken in je watervaldinges dan kun je al die vragen toch prima zélf beantwoorden? We zitten hier niet om handjes vast te houden en ik zou 't op prijs stellen als je zelf een beetje meer moeite deed behalve steeds domweg de volgende plugin (oppervlakkig) proberen en dan peeuwen als het niet meteen al je problemen oplost.

Verder: gebruik a.u.b. de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

Stab schreef op donderdag 08 oktober 2015 @ 00:24:
- Hoe kan dit? Ik heb volgens mij nergens een redirect staan. In ieder geval niet in htaccess.
- Zou dit met 'het probleem' te maken kunnen hebben? Dat er ergens een infinite loop van redirects bestaat ofzo?

Beide vragen kun je prima beantwoorden met voorgenoemd watervaldiagramdingesgeval. Je ziet dat de eerste request op het "naked domain" gewoon een 301 krijgt (na 4.46 seconden...). En je ziet ook dat er geen sprake is van "een infinite loop van redirects" (los van het feit dat browsers dat al sinds eeuwen 'detecteren' en na X pogingen gewoon afbreken). Ook de buttload aan CSS en JS bestanden helpt nou niet bepaald en hoeveel fonts gebruik je wel niet

[ Voor 73% gewijzigd door RobIII op 08-10-2015 00:58 ]

[Stab]

RobIII schreef op donderdag 08 oktober 2015 @ 00:34:
Als je nou eens gewoon op F12 mept en zélf gaat kijken in je watervaldinges dan kun je al die vragen toch prima zélf beantwoorden? We zitten hier niet om handjes vast te houden en ik zou 't op prijs stellen als je zelf een beetje meer moeite deed behalve steeds domweg de volgende plugin (oppervlakkig) proberen en dan peeuwen als het niet meteen al je problemen oplost.

Verder: gebruik a.u.b. de wijzig-link (rechtsbovenaan je post) als je iets toe te voegen hebt; je topic herhaaldelijk omhoogschoppen is niet nodig en die melding staat er niet voor niets:

[afbeelding]

[...]

Beide vragen kun je prima beantwoorden met voorgenoemd watervaldiagramdingesgeval. Je ziet dat de eerste request op het "naked domain" gewoon een 301 krijgt (na 4.46 seconden...). En je ziet ook dat er geen sprake is van "een infinite loop van redirects" (los van het feit dat browsers dat al sinds eeuwen 'detecteren' en na X pogingen gewoon afbreken). Ook de buttload aan CSS en JS bestanden helpt nou niet bepaald en hoeveel fonts gebruik je wel niet

Beste Rob,

Mijn excuses voor het omhoog kicken en voor mijn postgedrag.
Het is niet dat ik verwacht dat mensen het hier eventjes voor mij gaan oplossen, integendeel zelfs.
Maar ik ben geen echte webdeveloper, dat moge duidelijk zijn en ben dus overgeleverd aan templates en plug-ins. Nou is dat natuurlijk geen goede basis om hier te posten en dat begrijp ik.

Ik was gewoon verrast door het feit dat de pagina zo goed scoort op diagnostic tools als pagespeed en gtmetrix en vervolgens toch traag laadt en probeer daar op een zo duidelijk mogelijke manier en antwoord op te krijgen zodat ik desnoods iemand anders kan inschakelen om het op te lossen.

Maar omdat ik van allerlei experts continu iets anders hoor waar ik het in moet zoeken weet ik het op een gegeven moment ook niet meer. Eigen probleem, dat snap ik. Ik wil zo graag zonder veel technische kennis een website runnen dus dan zijn dit de gevolgen.

Sowieso iedereen bedankt die tot nu toe een steentje heeft bijgedragen en mij in de goede richting heeft gewezen. Ik vrees dat ik iemand ga inschakelen om het voor me op te lossen.

[sig69]

Ik was gewoon verrast door het feit dat de pagina zo goed scoort op diagnostic tools als pagespeed en gtmetrix en vervolgens toch traag laadt en probeer daar op een zo duidelijk mogelijke manier en antwoord op te krijgen zodat ik desnoods iemand anders kan inschakelen om het op te lossen.

Staar je niet blind op diagnostic tools. Wij hebben eens een seo "expert" over de vloer gehad en een van zijn punten was dat de homepage van onze site traag was. Onzin zei ik, die staat binnen een seconde op je scherm (en gaat daarna wat twitter feeds en facebook meuk ophalen). Ik heb het hem zelfs laten zien, met throttling op 3g zelfs, maar hij bleef hameren op de resultaten uit zijn tooltje.

[TheNephilim]

Welke plugins, maar vooral hoeveel plugins, heb je draaien?

[Stab]

TheNephilim schreef op donderdag 08 oktober 2015 @ 13:10:
Welke plugins, maar vooral hoeveel plugins, heb je draaien?

11 stuks.

- 404 to 301 - stuurt automatisch foute urls door naar homepage
- cmssuperheroes - benodigd voor theme
- Contact Form 7 - meest gebruikte contactformulier
- Leverage Browser Caching Ninja
- Remove query strings from static resources
- Revolution Slider
- Testimonial basics - Wordt gebruikt op 'recencies' pagina voor layout
- W3 total cache
- WPbakery Visual Composer - benodigd voor theme
- Yoast SEO - Meest gebruikte SEO / title generator

Best wel wat plug-ins dus, maar volgens mij allemaal vrij 'licht' en een aantal helaas benodigd.
Ik heb ze allemaal al eens ooit 'disabled' om vervolgens te kijken of het verschil maakt, maar dat doet het niet.

Wat ik raar vind is dat de www versie veel sneller is in diagnostic tools dan de non www versie. De 301 redirect die automatisch plaatsvindt duurt 3-4 seconden om te laden...
Zou wat hier gaande is ook van invloed kunnen zijn op de langzame laadtijden van de www versie als je die in je browser invoert?

[Verwijderd]

- 404 to 301 - stuurt automatisch foute urls door naar homepage

Deze zou ik dan maar even uitzetten en kijken hoe het dan gaat.

[Stab]

Verwijderd schreef op vrijdag 09 oktober 2015 @ 12:34:
- 404 to 301 - stuurt automatisch foute urls door naar homepage

Deze zou ik dan maar even uitzetten en kijken hoe het dan gaat.

Thanks. Ik heb die nu uitgezet en heb ook de slider vervangen door een embedded video en die dus ook uitgezet en verwijderd.

De www versie van de website scoort nu prima op pagespeed, al voelt hij wel nog enigzins traag bij vlagen. De non-www versie is echter verschrikkelijk en pagespeed geeft ook aan dat de server response time daar extreem lang is. Nog nooit zo lang gehad als laatste 2 testen zelfs... 9 seconden en 12 seconden...

Wordpress doet blijkbaar deze non-www naar www redirect automatisch omdat dit beter is voor SEO. Dat geloof ik, maar dit kan zo echt niet.

Als iemand nog een idee heeft voor dit laatste probleem, dan hoor ik het graag. Op internet weinig over te vinden.

[Jelmer505]

Als ik jou was zou ik die sowieso 1 redirect houden van non www to www of www to non www(snap je het nog ). Anders gaat google zeuren of duplicate content.

Zoals al eerder gezegd is blijf niet blind staren op pagespeed zo kijkt google naar jouw site niet de mensen die er op komen. Kijk naar dolfinarium deze pagina is heel snel maar scoort niet goed op PageSpeed Insights.

Wat misschien voor jou nog wel kan werken is http://www.cloudflare.com. Dit zorgt er voor dat je Website op steroids draait. Lees de website even rustig door!

Groeten ,
Jelmer

[RobIII]

Jelmer505 schreef op dinsdag 13 oktober 2015 @ 10:38:
Als ik jou was zou ik die sowieso 1 redirect houden van non www to www of www to non www(snap je het nog ). Anders gaat google zeuren of duplicate content.

Mensen kunnen we alsjeblieft ophouden deze mythe in leven te houden?

[Jelmer505]

RobIII schreef op dinsdag 13 oktober 2015 @ 11:28:
[...]

Mensen kunnen we alsjeblieft ophouden deze mythe in leven te houden?

Zelf werk ik bij een Online Marketing Bureau en heb zeker ervaring dat wanneer pagina's in eens dupliceren dit niet goed is voor je rankings in google.
Wel lekker offtopic dit

[André]

Jelmer505 schreef op dinsdag 13 oktober 2015 @ 11:35:
[...]


Zelf werk ik bij een Online Marketing Bureau en heb zeker ervaring dat wanneer pagina's in eens dupliceren dit niet goed is voor je rankings in google.
Wel lekker offtopic dit

Onzin, dubbele pagina's kunnen prima. Google heeft alleen een duplicate-content filter waardoor er vaak maar 1 van de 2 of meer dubbele getoond worden in de zoekresultaten. Zolang je dus maar een paar dubbele pagina's hebt is er weinig aan de hand. Dit kun je deels opvangen met een canonical, een juiste redirect in het geval van www of non-www (al snapt Google dit prima zoals Rob aangeeft), en parameter uitsluiting in de Search Console. Het heeft echt 0,0 invloed op je rankings, dat zou wat wezen, per ongeluk een pagina's dupliceren en hop: allebei dalen ze.

En om terug te keren op Dolfinarium: die laden direct een film in van minimaal 50MB, daarna heb ik hem maar uit gezet. Op de mobiele site alleen al 30 verschillende trackers die nogal vertragend werken. De site is verder wel netjes, maar dit soort dingen doet de andere optimalisaties te niet.

[ Voor 21% gewijzigd door André op 13-10-2015 12:08 ]

[Jelmer505]

Think again André...

quote: Matt Cutts

That’s correct. By far, the vast majority of sites are in the first realm, where PageRank plus other factors determines how deep we’ll go within a site. It is possible that host load can impact a site as well, however. That leads into the topic of duplicate content. Imagine we crawl three pages from a site, and then we discover that the two other pages were duplicates of the third page. We’ll drop two out of the three pages and keep only one, and that’s why it looks like it has less good content. So we might tend to not crawl quite as much from that site.
If you happen to be host load limited, and you are in the range where we have a finite number of pages that we can fetch because of your web server, then the fact that you had duplicate content and we discarded those pages meant you missed an opportunity to have other pages with good, unique quality content show up in the index.

[RobIII]

Jelmer505 schreef op vrijdag 16 oktober 2015 @ 15:10:
Think again André...

Voortaan even de bron erbij zetten (of erbij vermelden dat 't over een artikel uit 2010 gaat...). Daarbij wordt er niet gesproken over een penalty maar hooguit over een "gemiste kans" om meer (unieke) content te laten crawlen (i.p.v. die 3 duplicate pagina's had je de crawler 3 unieke pagina's kunnen voeren; het aantal requests dat een crawler kan/zal doen per tijdsperiode is niet oneindig ).

Maar als je voortaan het hele artikel erbij geeft dan kan iedereen voor zichzelf concluderen of je nu niet misschien toevallig ook wel een héél klein beetje 'gunstig' in je eigen straatje quote zonder de context / rest van 't artikel erbij te vermelden Begrijpend lezen is ook een vak

[ Voor 23% gewijzigd door RobIII op 16-10-2015 15:52 ]