H ρύθμιση του email στο Android σας, είναι ιδιαίτερα απλή.
Πρώτα φτιάξτε τον email λογ/σμό σας μέσα από το περιβάλλον διαχείρισης του web hosting που έχετε στην dnhost.
Ανοίξτε την εφαρμογή δημιουργίας ηλεκτρονικού λογαριασμού email. Πατήστε στο “Ρυθμίσεις” (στην Αγγλική έκδοση θα το βρείτε σαν Settings)
θα το βρείτε επάνω αριστερά στην οθόνη σας.
Επιλέξτε “Προσθήκη Λογαριασμού” (Add Account…)
Εισάγετε την Email διεύθυνση σας. Επιλέξτε “ΜΗ ΑΥΤΟΜΑΤΗ ΡΥΘΜΙΣΗ”
Επιλέξτε “POP3 ή IMAP” όχι EXCHANGE . Στο παράδειγμα, έχουμε επιλέξει IMAP.
Εισάγετε το Συνθηματικό (κωδικός/password) του λογαριασμού email που έχετε δημιουργήσει μέσα στο Plesk panel σας.
Στην περιοχή “Διακομιστή ΕΙΣερχόμενης αλληλογραφίας” (Incoming Mail Server) εισάγετε:
“Όνομα χρήστη” (Username): το email σας πχ user@domain.gr
“Κωδικός πρόσβασης” (Password): θα είναι ήδη συμπληρωμένο.
“Διακομιστής” (Host Name): mail.domain.gr (όπου domain.gr γράφετε το domain σας)
“Τύπος ασφάλειας” > Καμία
Πατήστε στο “Διακομιστή ΕΞερχόμενης αλληλογραφίας” (Outgoing Mail Server) εισάγετε το:
“Όνομα host” (Host name): mail.domain.gr (ΑΝΤΙ ΓΙΑ domain.gr γράφετε το domain σας)
“Θύρα” > 587
“Τύπος ασφάλειας” > Καμία
“Να απαιτείται σύνδεση” > Πάντα ‘τσεκαρισμένο’
“Όνομα χρήστη” (Username): το email σας πχ user@domain.gr
“Συνθηματικό” (Password): συμπληρώστε το password του email σας.
Επιλογές λογαριασμού
Επιλέξτε την συχνότητα συγχρονισμού (αν ακολουθήσατε τις οδηγίες για IMAP) στα 15 λεπτά.
Ολοκλήρωση ρυθμίσεων
Δώστε το όνομά σας (προαιρετικό) για τον λογαριασμό σας και για την εξερχόμενη αλληλογραφία.
Πατήστε επόμενο για να ολοκληρώσετε τις ρυθμίσεις του λογαριασμού σας.
Είσαστε έτοιμοι να πάρετε τα email σας στο Android!
H διαδικασία για το Android γενικά περιγράφεται και εδώ:
Επιλέγετε Settings > Personal > Accounts –> κλικ στο Add account –> κλικ στο Personal (POP3) ή Personal (IMAP) και ακολουθείτε τη διαδικασία.
he Critical Rendering Path is the sequence of tasks the browser performs to first render a page on the screen, i.e. to download, process and convert HTML, CSS, and JavaScript code into actual pixels, and paint them on the screen.
The Critical Rendering Path Optimization is the process of minimizing the time spent by the browser to perform each step of the sequence prioritizing the display of content related to the current user action.
Much of this process pertains to the portion of the page that is visible without scrolling down the browser window. That section is also known as Above the Fold. For a better usability, the ATF should be rendered as soon as possible, and this can be done reducing the number of network round trips at a minimum. The resources required to render the ATF are considered critical, and optimizing the Above the Fold means minimizing the impact of critical resources on the time to first render of the page.
In this post, we will walk through the Critical Rendering Path optimization sequence.
First, I will provide a general overview of the tasks the browser performs to render a page’s content.
Following, I will dissect the most relevant actions we can carry out to optimize the Critical Rendering Path.
Finally, I will list some useful (and popular) WordPress optimization plugins.
The Critical Rendering Path Sequence
Here is the sequence of steps performed by the browser to render a page:
First, the browser downloads and parses the HTML mark-up and builds the DOM
Then it downloads and processes the CSS mark-up and constructs the CSS Object Model
It combines DOM and CSSOM nodes required to render the page in the Render Tree, which is a tree structure of all visible nodes
It calculates dimensions and position of every object in the page
First, the browser reads the row bytes and translates them to individual characters
Then it converts the strings of characters enclosed within angle brackets into tokens
These tokens are converted into node objects
Node objects are linked in a tree-like data structure that contains HTML content, properties, and all the relationships between nodes. This structure is the Document Object Model.
What is important to note here is that the browser constructs the DOM incrementally. This gives us the opportunity to speed up the rendering of the page by creating efficient DOM structures.
DOM structure
The CSSOM
When the parser encounters a link tag that refers to an external CSS stylesheet, it blocks the parsing and sends out a request for this resource. Once the CSS file has been received, the browser starts building a tree data structure of CSS nodes.
The browser reads the row bytes of the .css file and translates them to individual characters
It converts the strings of characters enclosed within curly brackets into tokens
These tokens are converted into node objects
Node objects are linked in a tree-like data structure that contains the CSS properties of each node, and the relationships between nodes. This structure is the CSS Object Model (CSSOM).
Unlike DOM construction, CSSOM construction is not incremental. The browser can’t use a portion of a stylesheet, because styles can be refined and redeclared in the same stylesheet. For this reason, the browser blocks the rendering process until it receives and parses all the CSS. This means that CSS is render blocking.
CSSOM structure
The Render Tree
The browser combines DOM and CSSOM into the Render Tree, which is the final tree structure containing all nodes and properties that are being used to render the page to the screen.
The Render Tree only contains nodes that are required to render a page. As a consequence, invisible nodes are omitted.
The browser uses the Render Tree to calculate node dimensions and position, and ultimately as an input for the paint process.
Render Tree structure
Layout and Paint
In the layout stage, the browser calculates dimensions and position of each node of the Render Tree. In this stage, the browser traverses the Render Tree starting from its root and produces a box model. This information is finally used to convert each node of the Render Tree into actual pixels on the screen.
Critical Rendering Path Optimization
The time required to run the entire process can be variable. It depends on many factors like the document size, the number of requests, the applied styles, the user device, etc.
One of the most relevant Google recommendations is to prioritize visible content so to render the Above the Fold as quick as possible, and provides two main rules to follow:
Structure the HTML to load the critical, above-the-fold content first
Reduce the amount of data used by HTML, CSS and JS resources
As well explained in Google’s PageSpeed guide, if the amount of data required to render the ATF exceeds the initial congestion window (14.6kb), it will require additional network round trips between the server and browser. On mobile networks, with high latencies, this would significantly delay the page loading (read more on latency).
The browser builds the DOM incrementally, and this gives us the opportunity to reduce the time required to render the ATF by structuring the HTML so to load the above-the-fold first and defer the rest of the page.
The Above the Fold content varies depending on the user device
But optimization does not end with the construction of an effective DOM structure. Rather, it’s a process of improvement and measurement that involves the whole Critical Rendering Path sequence.
Let’s dive deep.
Minimize Resource Dimensions
We can reduce the amount of data the browser is going to download by minifying, compressing and caching HTML, CSS and JavaScript resources:
Minification is the process of removing unnecessary characters like comments and white space from the source code. These characters are extremely useful in development, but they’re useless for the browser in order to render the page.
Compression is the capability of web servers and clients to reduce the size of transmitted files in order to improve speed and bandwidth utilization
Caching: every browser comes with an implementation of an HTTP cache. What we need to do is ensuring that each server response provides the correct HTTP headers to instruct the browser on when and how long it should cache the requested resources
Optimize CSS
Now we know that the browser has to wait until it fetches and processes the CSS code before it can render the page (CSS is render blocking). But not all CSS resources are render-blocking.
CSS can be scoped to particular conditions, and we can optimize it using media types and media queries. If you’re viewing a webpage on the screen, the browser will send a request for print media type but it won’t block the rendering of the page for this resource.
Take the following link tag:
<link rel="stylesheet"href="style.css"/>
The referenced stylesheet of this tag applies under any condition, independently from the current media type, screen resolution, device orientation, etc. This means that the CSS resource is always render-blocking.
Luckily, we can send a request for a CSS resource under specific conditions. We could move print styles into a separate file and use the media attribute to tell the browser that the specified style sheet should only be loaded when printing the page, and it doesn’t need to block the rendering on the screen:
The browser still downloads the print.css stylesheet, but it won’t block the rendering. Moreover, the browser has to download less data for the main CSS file and this would help us speed up the download. We can specify any media query on the link attribute, so we can split the CSS into multiple files and load them conditionally:
Be sure your styles are actually required to render the page. If they’re not, you can add an appropriate value to media tag attribute and unblock rendering.
Media types and queries can help us to speed up the page rendering, but we can do a lot more.
Minify CSS: white space and comments only help us read CSS declarations. By removing comments and whitespace from the stylesheet we can significantly reduce the number of bytes of a CSS file
Combine multiple CSS files: this would reduce the number of HTTP requests. This action is particularly important in mobile connections, where performance is affected by high latency (read more on latency).
Inline critical CSS: some styles are critical in the sense that they are required to render the above-the-fold of the page. You should always consider inline critical styles directly into the HTML markup to avoid additional HTTP requests. But avoid inlining large CSS files, because this may require additional round trips to render the above-the-fold, and this would result in a PageSpeed warning.
Speed-up Layout and Paint Processes
The time spent by the browser to layout the document depends on the number of DOM elements to layout and on the complexity of those layouts.
If you have a lot of DOM elements, the browser could take a long time to calculate position and dimensions of them all: avoid layout whenever it’s possible.
Prefer the new Flexbox model, as it’s faster than old Flexbox and floating layouts.
Avoid forced synchronous layout with JavaScript
Computing element size and position takes time and reduces performance. Making the DOM as simple as possible, and avoiding the use of JavaScript to anticipate the layout process would help the browser to speed up the page rendering (read more on layout optimization).
Strictly connected to the Layout is the Paint process, which is probably the most time-consuming stage in the Critical Rendering Path sequence, because anytime you change the layout of an element or any non-geometric property the browser triggers a paint event. Making things as simple as possible at this stage could help the browser speed-up the paint process. For instance, a box-shadow property, which requires some sort of calculations, would take longer to paint than a solid border color.
Chrome DevTools allow to identify the portions of the page that are being painted
Optimizing the paint process may not be that easy, and you should make use of your browser’s developer tools to measure how long the browser takes to trigger each paint event. You can read more on this topic in Google’s Rendering Performance guide.
Make JavaScript unblocking
When the browser encounters a script tag it has to stop parsing the HTML code. Inline scripts are executed at the exact point where they are in the document and block the DOM construction until the JS engine finishes running. In other words, inline JavaScript can significantly delay the initial render of the page. But JavaScript also allows to manipulate CSS properties, so the browser has to pause the script execution until it has finished downloading and building the CSSOM, as well. This means that JavaScript is parser blocking.
In case of external JS files, the parser must also wait until the resource has been fetched from cache or remote server, and this could heavily slow down the time to first render of the page.
That being said, what can we do to minimize the time spent by the browser to load and execute JavaScript?
Load JavaScript asynchronously: the boolean async attribute of the script tag instructs the browser to execute the script asyncronously, if possible, without blocking the DOM construction. The browser sends the HTTP request for the script, and continues parsing the DOM. Also, the script does not block the CSSOM construction, meaning that it won’t block the Critical Rendering Path (see MDN docs for further information about script tag attributes)
Defer JavaScript: the boolean defer attribute of the script tag tells the browser to execute the script after the document has been parsed, but before firing the DOMContentLoaded event. This attribute must not be used if the src attribute is absent, i.e. inline scripts (read more on Mozilla Hacks)
Postpone inline JavaScript: many scripts do not manipulate the DOM or the CSSOM, so there is no good reason for them to block the parsing. Unfortunately, we can’t use async and defer attributes for inline scripts, so the only way to load them after the document has been loaded is moving them to the bottom. The advantage is that inline scripts do not require additional HTTP requests. However, inlining scripts used in several pages would result in redundant code.
Wrapping Up Optimization Rules
That’s a lot of stuff, isn’t it? Let’s take a breath, and write down a list of the optimization actions described so far.
Minify, compress and cache HTML, CSS and JavaScript resources.
Minimize use of render blocking resources (specifically CSS)
Use media queries on link tags
Split stylesheets and inline critical CSS
Combine multiple CSS files
Minimize use of parser blocking resources (JavaScript)
Use defer attribute on the script tags
Use async attribute on the script tags
Inline JavaScript and move script tags to the bottom of the document
Now that we know the basic concepts of Critical Rendering Path Optimization, we can have a look at some WordPress popular optimization plugins.
Optimizing the Critical Rendering Path in WordPress
WordPress users can take advantage of a number of plugins that cover almost every aspect of the optimization process. You can install a fully featured plugin, or you can install several plugins at once, each providing specific optimization features.
A few questions came up in our recent blog post, where we discuss XML-RPC brute force attacks, about disabling XML-RPC on WordPress. To allay any confusion, we thought we would describe exactly what XML-RPC does and whether you should consider disabling it.
XML-RPC on WordPress is actually an API or “application program interface“. It gives developers who make mobile apps, desktop apps and other services the ability to talk to your WordPress site. The XML-RPC API that WordPress provides gives developers a way to write applications (for you) that can do many of the things that you can do when logged into WordPress via the web interface. These include:
Publish a post
Edit a post
Delete a post.
Upload a new file (e.g. an image for a post)
Get a list of comments
Edit comments
For a full list of the WordPress API functions available to developers via XML-RPC, take a look at this page on the WordPress codex.
If you disable the XML-RPC service on WordPress, you lose the ability for any application to use this API to talk to WordPress.
Lets use an example to illustrate: You have an app on your iPhone that lets you moderate WordPress comments. Someone advises you to disable XML-RPC. Your iPhone app suddenly stops working because it can no longer communicate with your website using the API you just disabled.
To us, disabling XML-RPC comes with a cost. You are disabling a major API in WordPress. We briefly provided this capability, but removed the feature because WordPress’s own API abuse prevention has improved. Furthermore, providing the ability to disable XML-RPC caused confusion among users when their applications broke because they could not access the API.
Jetpack is one of the most popular plugins for WordPress and relies heavily on XML-RPC to provide its features. It is developed by Automattic, makers of WordPress. If you visit the “Known Issues” page for Jetpack, you’ll notice they discuss how certain security plugins can impact Jetpack features if you use them to disable XML-RPC.
The following two kinds of attacks on XML-RPC have received press coverage during the past 2 years.
DDoS via XML-RPC pingbacks. This is actually not a very effective form of DDoS and anti-spam plugins like Akismet have gotten good at spotting this kind of abuse.
Brute force attacks via XML-RPC. These are completely ineffective if you’re using Wordfence because we simply block the attacker after they reach the login attempt limit.
If you still want to disable XML-RPC, there are several plugins to choose from in the official WordPress repository. You will lose any XML-RPC API functionality that your applications rely on. We don’t disable XML-RPC on our own sites.
Το Phishing είναι ενέργεια εξαπάτησης των χρηστών του διαδικτύου, κατά την οποία ο ‘θύτης’ υποδύεται μία αξιόπιστη οντότητα, καταχρώμενος την ελλιπή προστασία που παρέχουν τα ηλεκτρονικά εργαλεία, και την άγνοια του χρήστη-‘θύματος’, με σκοπό την αθέμιτη απόκτηση προσωπικών δεδομένων, όπως είναι ευαίσθητα ιδιωτικά στοιχεία και κωδικοί
Αν ήταν εφικτό να αποδώσουμε τον όρο στα Ελληνικά, θα μπορούσαμε κάλλιστα να το αποκαλέσουμε ‘Ηλεκτρονικό Ψάρεμα’, κι αυτό γιατί αγγλικός όρος δεν απέχει πολύ από αυτό. όμως πως αυτό μπορεί να αφορά τους οικιακούς ή τους εταιρικούς χρήστες του διαδικτύου; πως μπορούμε να έρθουμε αντιμέτωποι με τέτοιες απειλές;
Η αλήθεια είναι πως καθημερινά μπορούμε να έρθουμε αντιμέτωποι με απειλές τύπου phishing. Οι προσεχτικοί χρήστες θα πουν πως δε τίθεται θέμα για αυτούς αφού ελέγχουν ενδελεχώς τη σύνδεση και το domain name της σύνδεσης στο internet.
Ένας κινέζος ερευνητής ασφαλείας Πληροφοριακών συστημάτων ανέφερε μια απειλή που είναι σχεδόν δύσκολο να εντοπισθεί. Προειδοποίησε πως hackers μπορούν να εκμεταλλευθούν ευπάθειες του Chrome, Firefox και Opera web browsers και να εμφανίσουν πλαστά domain names σαν τα νόμιμα domains υπηρεσιών όπως η apple, η google ή η amazon, έτσι ώστε να κλέψουν στοιχεία πιστοποίησης και άλλα ευαίσθητα προσωπικά δεδομένα.
Τι πρέπει να κάνουμε για αυτό; Γενικά ο έλεγχος του domain στο address bar αφού η σελίδα φορτώθηκε και εφόσον υπάρχει μια έγκυρη HTTPS σύνδεση είναι μια καλή λύση. Αλλά στη προκειμένη περίπτωση αυτό δεν είναι αρκετό. Αν ο browser απεικονίζει τη σελίδα “apple.com” στο address bar ασφαλισμένο με SSL αλλά το περιεχόμενο προέρχεται από άλλο server, τότε ο browser μας είναι ευπαθής στη homograph επίθεση.
Αυτή η επίθεση είναι γνωστή από το 2001 όπου οι πάροχοι περιηγητών προσπάθησαν να διορθώσουν αυτή την ευπάθεια. Είναι ένα είδος spoofing επίθεσης όπου οι χαρακτήρες έχουν αντικατασταθεί με Unicode χαρακτήρες. πολλοί Unicode χαρακτήρες, που αντιπροσωπεύουν αλφάβητα όπως το ελληνικό, το κυριλλικό, και το αρμένικο στα διεθνή domain names μπορούν να μοιάζουν το ίδιο με τους λατινικούς χαρακτήρες στο κοινό μάτι. Αυτό δε σημαίνει ότι αντιμετωπίζεται το ίδιο από τους υπολογιστές που διαβάζουν άλλους χαρακτήρες και προφανώς κατευθύνονται σε άλλες διευθύνσεις.
Για παράδειγμα το κυριλλικό a (U+0430) και το λατινικό a (U+0041) και τα δύο αντιμετωπίζονται διαφορετικά από τον υπολογιστή παρόλο που απεικονίζονται το ίδιο.
Έτσι οι προγραμματιστές των browsers χρησιμοποιούν την punycode κωδικοποίηση για να αντιπροσωπεύσουν τους Unicode χαρακτήρες στο URL και να αμυνθούν από τις homograph απειλές. όμως εδώ ανακαλύφθηκε μια ευπάθεια που δεν αφήνει τη punycode κωδικοποίηση να εκτελεστεί αλλά αυτό είναι ένα τεχνικό ζήτημα.
Αυτή η τρύπα έχει αναφερθεί στις εταιρείες με τους ευπαθείς browsers. Δεν είναι καθόλου περίεργο να αναφέρουμε πως σε αυτές συμπεριλαμβάνονται η Google και Mozilla .
Πλέον η google έχει ολοκληρώσει μια λύση καθώς η mozilla ακόμη ψάχνει να παράγει μια λύση.
Για τον firefox και για μια προσωρινή αντιμετώπιση κάντε τα εξής
1. πληκτρολογήστε στη μπάρα διεύθυνσης about:config
2. κατόπιν πληκτρολογήστε Punycode στη μπάρα αναζήτησης
3. οι ρυθμίσεις του Mozilla θα δείξουν το εξήςnetwork.IDN_show_punycode. Κάνε διπλό κλικ και επελεξε toggle και αλλαξε τη τιμή απο false σε true
Δεν υπάρχει κάτι παρόμοιο μεχρι στιγμής στο chrome ή στην opera για να απενεργοποιήσει τις αντικαταστάσεις. περιμένετε μεχρι το επόμενο update.
Υπάρχουν extensions που σας ειδοποιούν κάθε φορά που συναντάτε unicode χαρακτήρες σε κάποιο domain.
Ένας από τους καλύτερους τρόπους να προστατευτείτε από τα phishing attacks είναι ένας καλός password manager που έρχεται μαζί με add-ons και browser extensions που αυτόματα εισάγει τα στοιχεία σας στις σελίδες που πραγματικά αντιστοιχούν.
Έτσι όταν φθάνετε σε μια σελίδα που μοιάζει να είναι η πραγματική όπως η amazon ή η apple αλλά στην πραγματικότητα δεν είναι, τότε το πρόγραμμα κωδικών θα το εντοπίσει και δε θα κάνει αυθεντικοποίηση των στοιχείων. Με λίγα λόγια βρείτε και χρησιμοποιήστε ένα καλό πρόγραμμα κωδικών. Υπάρχουν αρκετά καλά και δωρεάν στο διαδίκτυο.
Τέλος οι χρήστες είναι καλό να πληκτρολογούν το domain name μόνοι τους και να μη χρησιμοποιούν ανακατευθύνσεις και συνδέσμους. Αυτό θα πρέπει να γίνεται ειδικά για τους τραπεζικούς σας λογαριασμούς.
Υπάρχουν πολλοί τρόποι να παρουσιάσεις την επιχείρηση σου στο διαδίκτυο. Ο δικός σας ιστότοπος είναι ένας από αυτούς. Άλλοι τύποι παρουσίασης είναι τα socialmediaκαι κανάλια που επιτρέπουν σε πελάτες να αναφέρουν τις επιχειρήσεις τους και να προβάλλονται μέσα από αυτά.
Πριν όμως αρχίσετε να κατασκευάσετε ένα websiteκαλό είναι να γνωρίζετε προσεγγιστικά τα κόστη, τα οφέλη και τα μειονεκτήματα από κάθε κατηγορία διαδικτυακής παρουσίας.
Αρχίζοντας τα κοινά σημεία των ιστότοπων και των αλλων μορφών διαδικτυακής προβολής παρέχουν τα εξής:
Προσέγγιση νέων πελατών
Διευκόλυνση στην αλληλεπίδραση χρήστη με την επιχείρηση (οπτικό υλικό, σχόλια επικοινωνία κλπ).
Αξιολόγηση από τους πελάτες και κριτικές
Εύρεση της επιχείρησης από desktopsκαι mobiles
Μπορείτε να χρησιμοποιήσετε εργαλεία όπως βραβεία, δώρα , επιβραβέυσεις
Χρειάζονται συνεχή συντήρηση (προστασία από hackers, απομάκρυνση spams, ανταπόκριση σε σχόλια).
Τι είναι όμως αυτό που διαφέρει στο να έχεις το δικό σου site :
Παρέχει το πλήρη έλεγχο για να παραμετροποιήσεις πολλά σημεία όπως τη δομή, το domainname, τον τρόπο παρουσίασης κλπ
Παίρνει περισσότερο χρόνο να στηθεί και είναι πιο δύσκολο έργο
Τι έχουν τα άλλα κανάλια που υπάρχουν διαθέσιμα:
Είναι είτε δωρεάν είτε με χαμηλά κόστη
Είναι ευκολότερο να στηθούν και να λειτουργήσουν άμεσα
Παρέχουν περιορισμένο έλεγχο για παραμετροποιήσεις και μειωμένη λειτουργικότητα
Αυτά τα σημεία είναι αρκετά για να σκεφτείτε τι θέλετε να πετύχετε και ποια είναι η καλύτερη επιλογή για εσάς και την επιχειρησή σας. Θέλετε απλά η δυνητικοί πελάτες να βρίσκουν τη διευθυνσή και το τηλεφωνό σας έτσι ώστε να σας καλέσουν απευθείας; Μια κατηγοριοποίηση σε μια λίστα επαγγελματιών θα ήταν αρκετή. Αν .ομως θέλετε ένα ηλεκτρονικό κατάστημα , ένα blogκαι λεπτομέρειες για το τι κάνετε, ποιες είναι οι υπηρεσίες σας κλπ , τότε το websiteέιναι η σωστή επιλογή. Επίσης αυτή είναι μια καλή στιγμή να σκεφτείτε πως σχεδιάζετε να συντηρήσετε τη δικτυακή σας προβολή και πόσο χρόνο και κόστος μπορείτε να αφιερώσετε.
Ανακεφαλαιώνοντας τα απραπάνω είναι αρκετά να αποφασίσετε αν θα κατασκευάσετε ένα siteβασιζόμενοι στο χρόνο , τις ανάγκες τους πόρους και τα ενδιαφέροντα σας.
Αν πήρατε την αποφαση να κατασκευάσετε ένα websiteείναι ώρα να επιλέξετε τα εξής:
Ένα domain name
Ένα website hosting
Domainname
Toόνομά σας είναι η ηλεκτρονική σας διεύθυνση άρα θα πρέπει να έχει τα εξής χαρακτηριστικά :
Περιγραφικό :Σκεφτείτε το όνομα της επιχείρησης και το περιεχόμενο το οποίο θα αναρτήσετε στη πορεία στον ιστότοπό σας. Το domainnameείναι το πρώτο που παρατηρεί ένας χρήστης άρα θα πρέπει να παρέχει μια καλή ιδέα για το τι πρόκειται να ακολουθήσει
Ευκολομνημόνευτο: Θα πρέπει να είναι εύκολο κάποιος να το θυμάται απλό και μικρό. Είναι δύσκολο για το κοινό να θυμάται μεγάλα και δύσκολα ονοματα
Προσαρμόσιμο: Θα πρέπει να μπορεί να ενσωματώνεται εύκολα σε νέες συλλογές, προϊόντα και νέες προωθήσεις. Άρα θα πρέπει να μην είναι εξειδικευμένο και απόλυτο για να μην περιορίζει την επιχείρηση.
Επιλογή καταχωρητή domain και παρόχου φιλοξενίας
Ο καταχωρητής domainείναι μια υπηρεσία που παρέχει ονόματα για δημόσια χρήση. Ο πάροχος φιλοξενίας από την άλλη παρέχει τη δυνατόητα αποθήκευσης αρχείων τα οποία έχουν τη δυνατότητα να γίνουν διαθἐσιμα από το κοινό στο διαδίκτυο. Πολλές εταιρείες και επιχειρήσεις πλέον παρέχουν ολοκληρωμένο πακέτο και των δυο. Τι θα πρέπει να προσέξουμε πριν κάνουμε την επιλογή μας
Uptime: Είναι ο χρόνος που οι serversείναι διαθέσιμοι στους πελάτες. Όλοι οι serversμπορούν να πέσουν κάποια στιγμή για λόγους συντήρησης ή ευπάθειας του συστήματος. Αναζητούμε servers με μικρό
Bandwidth :είναι το πλήθος των δεδομένων που μπορεί να στείλει ο ιστότοπός σας στο internetκαι καθορίζει την κίνηση που μπορεί να υποστηρίξει. Μερικοί πάροχοι έχουν απεριόριστο bandwidthενώ άλλοι θέτουν όρια. Προσοχή στην απεριόριστη κίνηση και στη πολιτική ορθής χρήσης που έχουν οι περισσότεροι.
Ασφάλεια : Θα πρέπει να μάθετε πώς να χειρίζεστε εργαλεία ασφαλείας για να προστατεύσετε το siteσας από ευπάθειες. Ελέξγτε επίσης αν παρέχεται βοήθεια όταν προκύπτει ζήτημα ασφαλείας
Υποστήριξη πελατών :Αν κάτι δε πάει καλά , θα πρέπει να ζητήσετε εξωτερική βοήθεια από την ομάδα του παρόχου, Διευκρυνήστε τι είδους βοήθεια θα είναι αυτή και ποσο σύντομα παρέχεται
Ευκολία χρήσης : Ελέγξτε την ευκολία της πλατφόρμας και το επίπεδο που χρειάζεται ένας χρήστης για να τη λειτουργήσει. Είναι σίγουρο πως μετά τη κατασκευή, θα πρέπει να μπορείτε να διαχειρίζεστε τη πλατφόρμα
Τιμή :Οι πάροχοι βγαίνουν στην αγορά με ένα εύρος τιμών και προσφορών. Θα πρέπει να ελέγξτετε τι παρέχουν και αν η μικρότερη τιμή της αγοράς σας ευνοεί σε αυτό που θέλετε να φτιάξετε. Συνήθως οι φθηνοί πάροχοι υπολείπονται σε λειτουργικότητα και υποστήριξη χωρίς αυτό να είναι ο κανόνας. Σε κάθε περίπτωση θα πρέπει να μιλήσετε με το τεχνικό σας και να καταλάβετε τι ανάγκες έχετε όσο αφορά τη λειτουργικότητα και τις απαιτήσεις σας .
Επιπρόσθετα services και χαρακτηριστικά: Ελέγξτε τις παροχές και τα επιπρόσθετα servicesπου χρειάζεστε όπως emailserversΚλπ.
Στο outlook όταν θα εισέλθετε, θα σας ζητηθεί ο κωδικός και θα πρέπει ο καθένας να εισάγει το δικό του στο mailbox του outlook. Επικοινωνήστε μαζί μας για να λάβετε το κωδικό του λογαριασμού σας
There’s nothing more worrisome and frustrating than browsing to your WordPress site and encountering a white screen with an error. Some common ones you might have experienced in the past include 502 bad gateway errors, the ever so popular white screen of death, or the frightening error establishing a database connection. For many blogs and ecommerce sites, these errors result in the loss of revenue from visitors instantly bouncing and customers unable to complete their purchases. Today we want to dive into the 504 gateway timeout error and some recommendations on how to fix it on your WordPress site. Read more below about what causes this error and what you can do to prevent it in the future.
Before diving into the error itself, it’s important to understand how they are generated. Whenever you launch your browser and visit a website it sends a request back to the web server it is hosted on. The web server then processes the request and sends back the requested resources along with what they call an HTTP header. This HTTP header contains one of many HTTP status codes to communicate whether everything is OK or if something has gone wrong. Not all HTTP status codes are bad. For example, a 200 status code means “Everything is OK.”
There are many different types of 500 status error codes (500, 501, 502, 503504, etc) which all have different meanings. These indicate that the request was accepted, but the server prevented the fulfillment of the request.
In this case, a 504 gateway timeout error means that “the server, acting as a gateway, timed out waiting for another server to respond.” The code returns when there are two servers involved in processing a request, and the first server times out waiting for the second server (upstream server), to respond (RFC 7231, section 6.6.5).
504 gateway timeout error in Chrome
504 Gateway Timeout Error Variations
Due to all the different web browsers, operating systems, and servers, a 504 gateway timeout error can present itself in a number of different ways. They all typically have the same meaning though. Below are just a few of the many different variations you might see pop up:
“504 Gateway Timeout”
“504 Gateway Timeout NGINX”
“NGINX 504 Gateway Timeout”
“Gateway Timeout Error”
“Error 504”
“HTTP Error 504”
“HTTP Error 504 – Gateway Timeout”
“HTTP 504”
“504 Error”
“Gateway Timeout (504)
“This page isn’t working – Domain took too long to respond”
“504 Gateway Time-out – The server didn’t respond in time”
A blank white screen
Some companies even have custom pages for 504 gateway timeout errors.
Github 504 error timeout
504 Errors Impact on SEO
Unlike 503 errors, which are used for WordPress maintenance mode and tell Google to check back at a later time, a 504 error can have a negative impact on SEO if not fixed right away. If your site is only down for say 10 minutes and it’s being crawled consistently a lot of times the crawler will simply get the page delivered from cache. Or Google might not even have a chance to re-crawl it before it’s back up. In this scenario, you’re completely fine.
However, if the site is down for an extended period of time, say 6+ hours, then Google might see the 504 error as a site-level issue that needs to be addressed. This could impact your rankings. If you’re worried about repeat 504 errors you should figure out why they are happening to begin with. Some of the solutions below can help.
Suffering from 504 gateway timeout errors? Follow these steps to resolve them. 👍CLICK TO TWEET
How to Fix the 504 Gateway Timeout Error
Where should you start troubleshooting if you see a 504 gateway timeout error on your WordPress site? Without a great deal of context, it can sometimes be frustrating and overwhelming where to even begin. Typically these are network connectivity issues and or problem with the server at which the site is hosted. However, it can also be a client-side issue, or even a result of a third-party plugin. So we’ll dive into a little of both. Check out these common causes and ways to fix the 504 gateway timeout error and get back up and running in no time.
1. Try Reloading the Page
One of the easiest and first things you should try when encountering a 504 bad gateway error is to simply wait a minute or so and reload the page (F5 or Ctrl + F5). It could be that the host or server is simply overloaded and the site will come right back. While you’re waiting, you could also quickly try a different browser to rule that out as an issue.
Another thing you can do is to paste the website into downforeveryoneorjustme.com. This website will tell you if the site is down or if it’s a problem on your side. A tool like this checks the HTTP status code that is returned from the server. If it’s anything other than a 200 “Everything is OK” then it will return a down indication.
downforeveryoneorjustme
2. Disable Proxy Settings
Sometimes you might see a 504 error if you are utilizing a proxy service. This is usually pretty rare, especially on the client-side. However, one might have been set without you even knowing it. Follow these tutorials on how to disable or check to ensure no proxy settings are enabled:
A 504 gateway timeout could also be because of a DNS issue. There are two sides to this, the first is on the server-side, such as the domain is not resolving to the correct IP. If you have just migrated your WordPress site to a new host, is it important to wait for things to fully propagate, which can take up to 24 hours in some cases. This depends upon the TTL value of your DNS records. You can use a free tool like DNSMap to check and see if your DNS has propagated around the globe.
Check DNS propagation
The second is a DNS issue on the client-side. In which case you could try flushing your local DNS cache. This is similar to clearing your browser cache.
In Windows simply open up Command Prompt and enter the following:
ipconfig /flushdns
Command prompt – flush DNS
You should see a “Successfully flushed the DNS resolver Cache” if it worked.
For macOS users, you can enter the following in the terminal:
dscacheutil -flushcache
Note: There is no success message on Macs.
And lastly, you could temporarily change your client-side DNS servers. By default, DNS servers are automatically assigned by your ISP. But you could try temporarily changing these to a public DNS server, such as Googles. In fact, some prefer to use Google’s public DNS long-term due to them sometimes being more reliable.
4. Temporarily Disable CDN
It could also be an issue with your content delivery network (CDN). If you are using a third-party CDN provider an easy way to troubleshoot this is to simply disable your CDN temporarily. For example, we are big fans of the free CDN enabler plugin. If you are using that, you can simply deactivate the plugin and then test your site. If you can’t access your site’s dashboard, simply log in to your site via SFTP and rename the plugin’s folder to cdn-enabler_old. This will temporarily disable the CDN connection. The same goes for WP Rocket or any other plugin you might have hooked up to your CDN.
Rename plugin folder temporarily
This can also occur sometimes with fully proxy services like Cloudflare or Sucuri, as they have extra firewalls in-between. Most of them actually cache 500 status codes when they are returned by your origin server. We have noticed that this happens once in a while on the Cloudflare free plan. Unfortunately, since Cloudflare is a fully proxy service, there is no quick way to simply disable it.
However, before you go pointing the finger at Cloudflare, it’s important to know that there are two different types of 504 gateway timeout variations as seen below:
504 Gateway Timeout at Cloudflare (Variation 1)
If you see the following screen, this is actually a problem on Cloudflare’s end, in which case you should reach out to them for support. Or check their status page. Most likely they are already aware of the issue and have their team working on it.
Cloudflare 504 gateway timeout
504 Gateway Timeout at Cloudflare (Variation 2)
If you see the following screen, this is a problem with your WordPress host (origin server), in which case you’ll want to skip down to recommendation #5 below.
Cloudflare 504 gateway timeout error at host
504 Gateway Timeout at Cloudflare with Uploads
Another reason for a timeout could be related to the size of your uploads. They do restrict POST (uploads) to 100MB on their free plan. However, we have occasionally seen clients have issues with files or uploads smaller than this. Sometimes this problem can be on your host’s end or Cloudflare. An easy way to determine which is simply is by bypassing Cloudflare with your DNS hosts file and trying your upload again. Or simply disable Cloudflare temporarily.
A server issue is one of the most common reasons users experience 504 gateway timeout errors on their WordPress sites. To put it layman’s terms, Nginx or Apache is waiting on a response from something and it timed out. We get a lot of clients that come to Kinsta due to the fact that they were constantly receiving these at other WordPress hosts. Here is an example of a conversation we receive on a regular basis.
We’re getting around 100k visitors per month with more than 200k views. We’re currently hosting with ____ and recently we experienced 504 errors due to server overload. I don’t like how ____ handled the problem and we were also advised that we will have to move to their dedicated plans soon, which I believe is not necessary.
504 errors do more often occur on high-traffic and ecommerce sites such as WooCommerce that have a lot of uncachable requests, as they sometimes can cause a server overload. However, we’ve seen these errors with all types of sites, even with simple blogs. Many hosts will simply reply back saying that you are required to upgrade to a high-tier plan to fix the issue. And while this most likely will get rid of most 504 gateway timeout errors, and is sometimes required, it’s not always necessary.
Here at Kinsta, we utilize LXD managed hosts and orchestrated LXC software containers for each site. This means that every WordPress site is housed in its own isolated container, which has all of the software resources required to run it (Linux, Nginx, PHP, MySQL). The resources are 100% private and are not shared with anyone else or even your own sites. Many shared WordPress hosts don’t have this capability and therefore a high-traffic neighboring site causing 504 gateway timeout errors, could very well impact your site.
Not only are your sites isolated, but our infrastructure was built to easily handle thousands of concurrent connections. Even MySQL databases are hosted at localhost, not a remote server. This ensures that there is no latency between machines, which results in faster queries and less chance of timeouts occurring anywhere in-between. Many clients who migrate to Kinsta see huge decreases in overall load times.
Besides server timeouts due to server load, here are few other reasons a server could be experiencing a 504 error:
Slow server: It could very well be the server your WordPress site is on is simply too slow to respond to the request and therefore it generates gateway errors.
Not enough PHP workers: PHP workers are used to execute the code on your WordPress site. On demanding sites it could very well be that all the PHP workers are busy, in which case they start to build up a queue. If the queue and backlog are full, old requests start to get disregarded. You can ask your host about increasing your number of PHP workers. Additional PHP workers per site allow for multiple requests to execute simultaneously.
Firewall issues: The firewall on your server could have some errors, an improper configuration, or rules preventing a connection from establishing properly.
Network connectivity: If there are problems with the network connection between the proxy server and the web server, it could cause delays in the response for the HTTP request. There could also be network connectivity issues with a load balancer if one is used.
HTTP timeouts: Can occur when the connection between your browser and the web server is held open for too long. These commonly happen when running WordPress imports. One way to resolve this is to switch to a faster internet connection. Or you can use a tool with support for WP-CLI, such as the WordPress Importer plugin, and run the import directly on the server, bypassing the HTTP connection entirely.
It’s also important to note that 504 errors can deceptively look a lot like 503 service unavailable errors or even 502 bad gateway errors, but they are in fact different. If you are experiencing a 504 error at Kinsta simply open a support ticket and we’ll get it fixed immediately. We also proactively monitor errors like these with New Relic, so more than likely our team is already investigating.
WordPress support ticket
If you are worried about these happening on your site in the future, you can also utilize a tool like updown.io to monitor and notify you immediately if they occur. It periodically sends an HTTP HEAD request to the URL of your choice. You can simply use your homepage. The tool allows you to set check frequencies of:
15 seconds
30 seconds
1 minute
2 minutes
5 minutes
10 minutes
It will send you an email if and when your site goes down. Here is an example below.
Email notification of 504 error
This can be especially useful if you’re on a shared host, who tend to overcrowd their servers. This can give you proof of how often your site might actually be doing down (even during the middle of the night). That’s why we always recommend going with a managed WordPress host. Make sure to check out our post that explores the top 9 reasons to choose managed WordPress hosting.
6. Spam, Bots, or DDoS Attack
It very well could be that your site is getting spammed by bots or is undergoing a DDoS attack. Sometimes these can result in uncached requests and could overwhelm the server resulting in 504 gateway timeout errors. You can take a look at your server analytics and see if you can spot any patterns. Here at Kinsta, we provide this data in our MyKinsta analytics tool. You could also ask your host for this data. The first report we recommend looking at is the top client IPs. This can be very helpful if your site is suddenly generating a lot of bandwidth or getting hit by bots.
Geo & IP – top client IPs
The second report we recommend looking at is the cache analysis. Here you can see how many requests are bypassing the cache, missing the cache, and the top locations on your site. For performance and stability reasons, you want as many requests to be cached as possible. This is not always possible though as sites such as those running WooCommerce generate a lot of un-cachable requests, and have to for features as the shopping cart and checkout process to work correctly and stay in sync.
Cache analysis
If you spot and or identify traffic/IPs that should be blocked on your site, you can use a WordPress security plugin to help. However, if you’re a Kinsta customer we typically don’t allow security plugins for a couple of reasons. First of all, they can have a huge effect on your performance, especially the scanning capabilities. Second, we utilize load balancers with Google Cloud Platform, which means a lot of time their IP blocking functionality wouldn’t work as intended.
Of course, IPs can always be blocked by our Kinsta support team, but depending upon the length and scale of the attack, this could be a never-ending process of blacklisting IPs, which in most cases doesn’t solve the problem fast enough. A lot of attacks or spamming when blocked in one area, will simply pop up in another, or change IPs and proxy addresses. So in this instance, we recommend that the client utilize a security solution such as Cloudflare or Sucuri.
Many might say that third-party plugins or themes don’t cause 504 gateway timeout errors. And in most cases, they don’t. However, in our experience, a slow uncached request from a plugin can indeed result in delays as this ties up more of your PHP workers. Once you’ve reached your limit of PHP workers, the queue starts to push out older requests which could result in 504 errors. This is not to be confused with 502 gateway errors in which the error occurs after a timeout of 60 seconds in the queue.
A few ways you can troubleshoot this is by deactivating all your plugins. Remember, you won’t lose any data if you simply deactivate a plugin. If you can still access your admin, a quick way to do this is to browse to “Plugins” and select “Deactivate” from the bulk actions menu. This will disable all of your plugins.
Deactivate all plugins
If this fixes the issue you’ll need to find the culprit. Start activating them one by one, reloading the site after each activation. When you see the 504 gateway timeout return, you’ve found the misbehaving plugin. You can then reach out to the plugin developer for help or post a support ticket in the WordPress repository.
If you can’t access your admin you can FTP into your server and rename your plugins folder to something like plugins_old. Then check your site again. If it works, then you will need to test each plugin one by one. Rename your plugin folder back to “plugins” and then rename each plugin folder inside of if it, one by one, until you find it. You could also try to replicate this on a staging site first.
Rename plugin folder
Always makes sure your plugins, themes, and WordPress core are up to date. And check to ensure you are running a supported version of PHP. You can always reach out to your host for assistance. We utilize New Relic and other troubleshooting methods here at Kinsta to help clients narrow down what plugin, query, or script might be causing the error. You can also use your own custom New Relic key.
Time-consuming queries to database
If it turns out to be an efficient query or bad code in a plugin, you might need to bring in a WordPress developer to fix the issue.
8. Check Logs
You should also take advantage of your error logs. If you are a Kinsta client, you can easily see errors in the log viewer in the MyKinsta dashboard. This can help you quickly narrow down the issue, especially if it’s resulting from a plugin on your site.
Check error logs for 502 bad gateway errors
If your host doesn’t have a logging tool, you can also add the following code to your wp-config.php file to enable logging:
You can also check the log files in Apache and Nginx, which are commonly located here:
Apache: /var/log/apache2/error.log
Nginx: /var/log/nginx/error.log
If you are a Kinsta client you can also take advantage of our analytics tool to get a breakdown of the total number of 504 errors and see how often and when they are occurring. This can help you troubleshoot if this is an ongoing issue, or perhaps something that has resolved itself.
Response analysis 500 error breakdown
9. Nginx Settings
If you are managing your own server and WordPress sites on Nginx + FastCGI (php-fpm) or Nginx as proxy for Apache, there are some additional settings you can change to help prevent 504 gateway timeout errors.
504 Gateway Timeout Error on Nginx + FastCGI (php-fpm)
If you are using Nginx with FastCGI (php-fpm) then you’ll need to first make a change to your PHP-FPM file. Navigate to /etc/php5/fpm/pool.d/www.conf (may vary based on PHP version). Set the following directive:
request_terminate_timeout =300
Next, you must change your php.ini file, which is typically located at /etc/php.ini. Search for the max_execution_time directive. Increase the value to 300, if the directive is not already present, then add it:
max_execution_time =300
Lastly, you’ll need to modify your nginx.conf file. Add the following inside your Nginx virtual host configuration.
location ~.php$ {...
fastcgi_read_timeout 300;}
Then simply reload Nginx as well as PHP-FPM.
service nginx reload
service php5-fpm reload
504 Gateway Timeout Error on Nginx Proxy
If you’re using Nginx as a proxy for Apache, add the following to your nginx.conf file:
As you can see, there is a multitude of different ways to troubleshoot and fix 504 gateway timeout errors on your WordPress site. Typically these are a server issue, in which case you can quickly reach out to your host to get it resolved. But it’s also important to understand they can actually be caused by third-party plugins or overwhelming your PHP workers queue/backlog.
If you are indeed maxing out your PHP workers, we recommend reaching out to our support here at Kinsta or hire a WordPress developer who specializes in web performance optimization. If after digging into your site you discover that your plugins, theme, and queries are fine, it might very well be that you do need to upgrade your plan or number of PHP workers.
Was there anything we missed? Perhaps you have another tip on troubleshooting 504 gateway timeout errors. If so, let us know below in the comments.
If you enjoyed this article, then you’ll love Kinsta’s WordPress hosting platform. Turbocharge your website and get 24/7 support from our veteran WordPress team. Our Google Cloud powered infrastructure focuses on auto-scaling, performance, and security. Let us show you the Kinsta difference! Check out our plans
Κοινωνικά Δίκτυα –Ποιο το αντίκτυπο στη κοινωνία και τι πρέπει να προσέχουμε
Ένα μεγάλο ζήτημα που απασχολεί τελευταία τη κοινωνία μας είναι η χρήση των socialmedia και η επίδραση που έχουν στη καθημερινή μας ζωή. Στις μέρες μας τα socialmediaθεωρούνται απαραίτητα για κάθε νέο και όχι μόνο. Αυξημένα ποσοστά νέων εγγραφών και χρήσης των κοινωνικών μέσων παρατηρούνται ακόμη και σε μεγαλύτερες ηλικίες. Όμως πολύ συζήτηση έχει γίνει για τα θετικά και αρνητικά της χρήσης αυτών των μέσων. Έχουν παρατηρηθεί ακραίες συμπεριφορές στη χρήση, έχουν κατηγορηθεί για την εθιστική τους δράση και τις αρνητικές επιπτώσεις σε νέους κυρίως χρήστες. Ας δούμε λοιπόν τα θετικά και αρνητικά γύρω από τα μέσα.
Πλεονεκτήματα και οφέλη από τα κοινωνικά μέσα
Παγκόσμια διασύνδεση
Δεν έχει σημασία ποιον ψάχνεις ή που βρίσκεται αυτός που ψάχνεις. Θα μπορούσατε να τον εντοπίσετε πολύ εύκολα και να έχετε μια επαφή παρότι ήσασταν χαμένοι πολύ καιρό και παρότι οι δρόμοι σας χώρισαν κάποια στιγμή στο παρελθόν. Η επικοινωνία είναι τόσο έυκολη και απλή που πλεον μπορείτε να τον έχετε εικονικά στη ζωή σας.
Επίσης είναι δυνατόν να δημιουργήσετε νέες διαδικτυακές φιλίες, να ενισχύσετε το επαγγελματικό σας πεδίο καθώς και να επεκτείνεται το κύκλο μέσα από το φιλικό σας περιβάλλον.
Θα μπορούσε κάποιος να πεί πως έτσι ενισχύεις κάποιες καταστάσεις όπως το να
αναζήτήσεις εργασία
αναζητήσεις βοήθεια
μοιραστείς τις πεποιθήσεις σου
να έχεις πρόσβαση σε νέα και γεγονόντα σε πραγματικό χρόνο
Προσβαση σε κοινότητες κοινών ενδιαφερόντων
Είναι μια διαδικασία που έρχεται να ενισχύσει τα κοινωνικά δίκτυα. Σε αυτά μπορείς να ενσωματωθείς και να προσεγγίσεις άτομα με κοινά ενδιαφέροντα, έτσι ώστε να μοιράζεσαι πληροφορίες , να εμπλουτίζεις τις γνώσεις σου και να αλληλεπιδράς με άτομα που θεωρούσες αδύνατον να έρθεις σε επαφή με άλλο τρόπο.
Διαμοίραση πληροφοριών σε πραγματικό χρόνο
Παλαιότερα θεωρούνταν αδύνατον να ενημερωθείς άμεσα και μάλιστα από μια πληθώρα μέσων έτσι ώστε να διασταυρώσεις τη πληροφορία. Τώρα αυτό είναι πάρα πολύ εύκολο χωρίς ιδιαίτερη προσπάθεια και αναζήτηση. Επίσης μπορεί κάποιος να κερδίσει πολύτιμο χρόνο χωρίς να μετακινείται σε χώρους αλλά να εκμεταλλεύεται από απόσταση πλατφόρμες εκπαίδευσης και επικοινωνίας.
Στοχευμένες διαφημίσεις
Πολύς λόγος έχει γίνει για τις στοχευμένες διαφημίσεις. Όμως είναι αυτό τόσο αρνητικό; Είτε κάποιος έχει επιχείρηση είτεμη κερδοσκοπικό οργανισμό, μπορεί να προωθήσει το μήνυμά του στο ευρύ κοινό μέσω των μέσων. Παρόλο όμως που δίνεται η δυνατότητα της προβολής, αυτό δε θα βοηθούσε τόσο αν δεν υπήρχε η δυνατότητα να προσεγγίσουν εκείνο το κοινό που τους ενδιέφερε. Έτσι με αλγορίθμους εντοπισμού του targetgroup τους, μπορούν να προβάλουν το μηνυμά τους.
Είναι όμως τόσο αθώα τα κοινωνικά μέσα δικτύωσης;Ποια μπορεί να είναι τα μειονεκτήματα;
Αντίκτυπο σχολίων και δημοσιεύσεων
Ενά κακό σχόλιο ή μια άσχημη συμπεριφορά στη ζωή μας μπορεί να είναι μια κακή στιγμή ενός ανθρώπου που μπορεί να ξεχαστεί. Όμως το ίδιο δε συμβαίνει στα κοινωνικά δίκτυα. Όταν ένα αρνητικό σχόλιο ή δημοσίευση αναρτηθεί στο διαδίκτυο, η έκθεση έχει άλλες διαστάσεις. Το αντίκτυπο μπορεί να είναι αρνητικό για το χρήστη. Πολλές φορές έχει καταστροφικές συνέπειες ακόμα και στο μακροπρόθεσμο μέλλον. Μπορεί να επηρεάσει ακόμη και τη καριέρα ενός ατόμου αφού λόγω αναρτήσεων ή σχολίων μπορεί να απορριφθεί από μια θέση εργασίας. Ο σύγχρονος κόσμος έχει πέσει θύμα της υπερβολικής διαμοίρασης πληροφοριών και αυτό έχει τις συνέπειές του
Δικτυακός εκφοβισμός και εγλήματα κατά των παιδιών
Η χρήση των κοινωνικών μέσων είναι επικίνδυνη για τους ανήλικους αφού είναι εύκολο να εκτεθούν σε πορνογραφία ή άλλο ακατάλληλο υλικό. Αυτό μπορεί να αποφευχθεί μόνο με εργαλεία φιλτραρίσματος αλλά και με κάποια επόπτευση από τους γονείς. Πέρα όμως απο το ακατάλληλο περιεχόμενο, η ψηφιακή εποχή γέννησε και μια νέα μορφή εκφοβισμού, το ψηφιακό εκφοβισμό, το λεγόμενο cyberbullying. Η διαφορά με το κλασσικό παραδοσιακό εκφοβισμό δεν περιορίζεται σε φυσική παρέμβαση. Μπορεί να συμβεί καθόλη τη διάρκεια της ημέρας, κάθε ημέρα και χωρίς τη παρουσία τπου χρήστη, αυτή να αναπαράγεται εκθετικά.
Κίνδυνος απάτης ή πλαστογραφία.
Είναι γεγονός πως όλες σχεδόν οι πληροφορίες που μοιραζόμαστε στο διαδίκτυο είναι διαθέσιμες σχεδόν σε όλους. Δεν είναι πολύ δύσκολο για κάποιον που θέλει να τις αποκτήσει να βρει τρόπο πρόσβασης σε αυτές ακόμα και αν θεωρείται πως έχετε ενεργοποιήσει δικλείδες ασφαλείας. Αυτό μπορεί να κοστίσει ακριβά σε κάποιους αφού ένας απατεώνας μπορεί να κάνει τη ζωή σας κόλαση. Στατιστικά φαίνεται πως οι περισσότερες κλοπές σύμβαίνουν στη νέα γενιά που δεν έχει αναστολές να μοιράστει απλόχερα τις προσωπικές της πληροφορίες.
Χάσιμο χρόνου
Παρότι μπορούμε να εκπαιδευτούμε, να ενημερωθούμε, να αλληλεπιδράσουμε κλπ, είναι γεγονός πλέον πως τα κοινωνικά μέσα μπορεί να είναι το περισσότερο διαστημα απλά χαμένος χρόνος. Η μεγαλύτερη κίνηση στο διαδίκτυο γίνεται από τα κοινωνικά μέσα και στατιστικά το 60% αυτών από κινητές συσκευές. Επίσης το 28 % του χρόνου μας ξοδεύεται στα κοινωνικά μέσα και ατό το ποσοστό αυξάνεται συνεχώς. Επίσης ένα κομμάτι του χρόνου στα κοινωνικά μέσα ξοδεύεται σε ώρες εργασίας. Αυτό σημαίνει απώλειες για την επιχείρηση και ξανά χαμένος χρόνος.
Επιχειρηματική εισβολή στην ιδιωτικότητα.
Οι κοινωνικές πλατφόρμες προσκαλούν μεγάλες επιχειρήσεις να ειβάλουν στα προσωπικά δεδομένα των χρηστών και να προωθήσουν τα προϊόντα τους. Σε όλους θα έχει τύχει να κάνουν ένα σχόλιο ή μια ανάρτηση και στη συνέχεια να δουν σχετική διαφήμιση. Για παράδειγμα το facebook υπολογίζεται πως κέρδιζει 16 τρισεκατομμύρια ανά έτος. Αυτό είναι ένα πολύ καλό κέρδος για μια δωρεάν πλατφόρμα. Αρά λοιπόν πως αυτά βγάζουν χρήματα; Ακριβώς χρησιμοποιώντας αλγορίθμους για τις στοχευμένες διαφημίσεις. Επομένως αντιλαμβανόμαστε πως το προϊόν στη προκειμένη περίπτωση δεν είναι η πλατφόρμα αλλά ο ίδιος ο χρήστης.
Είναι ένα μοναδικό όνομα το οποίο μπορεί να διαβαστεί και να συλλαβιστεί από άνθρωπο και αποτελεί την διαδικτυακή διεύθυνση του της ιστοσελίδας ή του ιστότοπου. Αποτελείται από 3 μέρη και αυτά είναι το top-level domain ή extension ή domain suffix, το domain name (ή ip διεύθυνση) και ένα subdomain
Εικονα 1
Ο συνδυασμός του top level domain και του domain ονομάζεται και root domain το Μπροστινό τμήμα http:// είναι είναι μέρος του URL και ονομάζεται πρωτόκολλο.
Τα top level domain (TLD) είναι η επίσημη ονομασία για τα suffixes που εμφανίζονται στο τέλος της ιστοσελιδας
Αυτά περιλαμβάνουν τα
.com
.org
.gr
.eu
Υπάρχουν πάνω από 1000 TLDs να επιλέξετε. Πιο σπάνια είναι π.χ. το .book , . clothing κλπ
Συνήθως χρησιμοποιούμε τα country specific TLDs τα οποία και είναι η συντομεύσεις από τις χώρες στις οποίες βρίσκονται οι επιχειρήσεις. Πχ .gr(greece), .eu(united Kingdom) κλπ
Τα domain names
Τα domain names είναι τα αδευτερα σε ιεραρχία μετά τα top level domains. Είναι χαρακτηριστικά σε κάθε συγκεκριμένο TLD και ενοικιάζονται από τους κατά τόπους καταχωρητές. Αυτά υποδηλώνουν τη διαδικτυακή τοποθεσία μια ιστοσελίδας ή ενός portal. Για παράδειγμα το : innocentric.gr αποτελεί το domain name του .gr TLD
Έτσι είναι δεδομένο πως σε κάθε ιστοσελίδα θα πρέπει να υπάρχει ένα root domain το οποίο και υποδηλώνει κατά πλειοψηφία την αρχική κεντρική σελίδα ενός site. Γνωρίζοντας λοιπόν το ROOT DOMAIN ΚΑΙ ΤΟ EXTENSION μπορούμε με σιγουριά να μετακινηθούμε στη μονιδική τοποθεσία της ιστοσελίδας αυτής.
Τακτικές επιλογής domain names
SEO BEST PRACTICES
Να είναι εύκολα απομνημονεύσιμο και ευκολο στην αναγνωση και στη γραφή
Να χρησιμοποιούνται λέξεις κλειδιά και να είναι ένα πιασάρικο domain αλλά δεν χρειάζεται μεγάλο φόρτο και πολλές λέξεις διοτι μπορεί να θεωρηθεί αρνητικός παράγοντας από την google. Για παραδειγμα το κατάστημά που είναι ειδικό στο να φτιάχνει pancakes θα μπορούσε να κάνει χρήση του best-pancakes.com αλλά θα ήταν περιττό να αναφέρει περισσότερα στο domain του.
Αποφυγή παύλας στα domains αν είναι εφικτό για την αποφυγή σύνδεσης με spam συμπεριφορές
Να χρησιμοποιείται καταλήξεις TLDs που υποδηλώνουν ποιος είστε και που εδρεύει η επιχειρηση σας. Για παράδειγμα μια ελληνική επιχείρηση καλό θα ήταν να χρησιμοποιήσει το .gr αν έχει ελληνικό περιεχόμενο τοποθετείται στον ελληνικό χώρο και απευθύνεται σε έλληνες κυρίως. >Φυσικά για μια επιχείρήση που απευθύνεται σε όλο τον κόσμο θα προτιμούσαμε το .com το οποίο είναι το πιο δημοφιλες TLD , δε σχετίζεται με spammy συμπεριφορές και έιναι ψηλά στη δημοφιλία.
Κάνετε χρήση subfolders/subdirectories kai oxi subdomains . τοποθετειστε υλικό σε κάποιο φάκελο του domains σας όπως για παράδειγμα ένα blog σε φάκελο του κεντρικού domain πχ. Mydomain.com/blog Και όχι σε κάποιο subdomain όπως blog.mydomain.com
Δεν έχει σημασία η ηλικία του domain name. Δε λαμβανεται υπόψιν η χρονολογία καταχώρησης ενός domain αλλά το υλικό και η πρωτοτυπία του
Προσοχή στη μετακίνηση domain και στο τρόπο που θα γίνει το redirect των pages. Αν και είναι συνηθης πρακτική να κάνουμε redirect τα pages στο κεντρικό homepage σε migration κατάσταση αυτό δεν είναι η καλύτερη πρακτική. Καλό θα ήταν να γίνει εξειδικευμένο redirect για κάθε page.
