Debat
|
Kære Aminoer |
|
Hej Tommy Tusinde tak for dit svar! Det vil jeg prøve at kigge på i aften!
|
|
Hej, Googles Pagespeed Insights skriver: Fjern ressourcer til blokering af gengivelse? :) Hvilke cache-plugin bruger du? Jeg ved at der findes en masse super gode plugins til WordPress... Så måske du skulle prøve med en anden, og se om ikke dét løser dit problem?
- Louise |
|
Hvis man rammer siden uden cache er den ufattelig langsom - dette vil oftest være tilfældet såfremt folk faktisk ligger ting i kurven - så et caching plugin virker måske for folk der ikke smider noget i kurven på din side, men loading tiden vil stadig være langsom for folk der faktisk gør. Den dårlige loading tid (server-side) kan der være mange grunde til, f.eks: - Forkert PHP version (brug 7.x hvis muligt) Istedet for at omgå problemet med et caching plugin, så istedet spørg din udbyder om de kan hjælpe dig med at se hvor problemet ligger i form af loading tid. Der er selvfølgelig intet galt med caching og er klart anbefalet, men det bør ikke være "løsningen" på problemet. Du kan også kontakte mig på lucas@hosting4real.net - så kan jeg tage en kopi af siden, smide på et webhotel hos os, hvor vi har adgang til New Relic, der kan pinpointe hvorpå loading tiden bruges. Selvfølgelig kvit og frit :) |
Hosting4Real - High performance webhoteller.
|
Kære alle Amino'er Tusinde tak for alle svarerne. Jeg har helt sikkert noget at arbejde med nu, og i har virkeligt give nogle gode værktøjer! TAK! :) |
|
Der er også et andet problem, som jeg synes man ser mere og mere med Woocommerce/Wordpress. På din side er der pt. næsten 50 kald til enten css eller javascript af mange forskellige modulers scripts. I en rigtig god programmering er der måske max 5 kald, fordi alt css/js bliver samlet i få filer. I stedet for at bruge Google PageSpeed og pingdom, kan man nu også bruge et mere avanceret værktøj som Google har udviklet: "Lighthouse", det findes som modul til Chrome. |
Meh, siden bruger http2 - derfor har det ikke betydning at der er 50 filer - du sender alt over en enkelt stream anyway. Det anbefales faktisk at du har flere filer når der bruges http2, fordi browserens render engine og main thread først begynder processing af en fil når hele filen er hentet - så hvis man har flere filer, betyder det du kan optimere din "first paint" tid, derved forbedre du den perceived performance for dine brugere, og øger konverteringerne. Snakker vi i oldtiden hvor at http2 og QUIC (snart http3) ikke var en ting, jo så havde det betydning om du skulle sende 5 eller 50 til brugeren, fordi du var begrænset af concurrency per hostname - det er dog ikke tilfældet mere.
Det samme ville ske hvis der var 5 filer. Problemet er at mobiler er underpowered sammenlignet med desktop, så din render engine vil stadig blive blokeret når javascript skal køres. Hvad der derimod skulle gøres, er at kigge på hvad javascript der er brug for på siden for mobiler, og fjerne alt det andet - men det har ikke rigtigt noget med antallet af filer at gøre eller antallet af plugins, men mere et design af siden :) Der var en grund til at Google lavede AMP - fordi man netop ville levere det "bare minimum" for at have en funktionel side. |
Hosting4Real - High performance webhoteller.
|
@Lucas Ok, jeg har bare hørt at minification og compile altid giver bedre resultat, end mange enkeltfiler. Især hvis man bruger et værktøj som Babel.io. https://babeljs.io/. Babel er et ret interessant projekt, som er sponsoreret af Adobe og AMP Project, bl.a. |
minification er ikke det samme som at combine/concatenate dine filer. Minification er at fjerne whitespace, kommentarer og omskrive koden til et mindre format i form af variablenavne bliver lavet så lille som overhovedet muligt Combine/concatenate er at sammensætte flere filer til én - dette har betydning i HTTP/1.0 og 1.1, fordi du som nævnt tidligere er bundet af concurrency per hostname. Størrelsen af siden vil være en smule større ved flere filer, fordi din gzip compression ratio vil blive mindre - men forskellen i størrelse (vi snakker mindre end et par kilobyte for en større side), er ikke nok (selv på 3G forbindelser) til at give en længere loading tid for browseren, end hvis du levere flere små filer, hvorpå du kan starte din rendering hurtigere, og derved øge perceived performance. Med nyere teknologier så som Brotli og lign, som er godt på vej, både i form af webserver support og browser support (Brotli er f.eks understøttet af alle major webservere så som nginx, LiteSpeed og Apache), vil du igen kunne vinde de få ekstra bytes. Med QUIC løser man nogle af de tekniske problemer som HTTP/2 ikke fik implementeret, eller som HTTP/2 skabte (f.eks, at HTTP/2 er mere prone til høj latency, pakketab og link congestion) - QUIC løser disse problemer relativt godt - og da IETF er ved at færdiggøre specifikationen til HTTP/3 (som reelt set er QUIC), så vil det også betyde mere browser og webserver support.
Hvis du endelig skal samle ting i mindre antal filer, så gør det i et par stykker og ikke i én. Du blokere din render engine helt ekstremt hvis du har én stor CSS fil f.eks. Man kan samtidig kigge på CCSS for at gøre "first paint" endnu hurtigere ved at kun have "above the fold" eller "viewport" styling. Der kan selvfølgelig gøres meget ved optimering af hastighed, og ret ofte er det nemt at hive loading tid hjem på en side (f.eks, stoppe med at bruge webfonts) - men med HTTP/2 og QUIC værende en ting som langt størstedelen af browsere understøtter (Især HTTP/2) - så er combine/concatenate ikke det sted hvor man vinder noget, tværtimod kan du forringe "first paint" ved at bruge det. |
Hosting4Real - High performance webhoteller.
Bliv gratis medlem
Opret bruger